人工智能全生命周期安全风险与DevSecOps治理框架深度分析

字数

46906 字

阅读时间

182 分钟

摘要

人工智能（AI）作为信息技术的软件、数据、算法的深度融合与演进，正以前所未有的速度重塑技术格局与社会结构。这种融合特性使其内生和应用安全风险复杂多样，且贯穿其整个生命周期。本文基于对现有研究文档和在线深度搜索结果的全面梳理与分析，旨在构建一份详细且具有深度的AI安全分析报告。报告系统性地识别并阐述AI在数据采集、模型开发、训练、验证、部署、应用到维护等各环节面临的核心安全挑战，深入剖析数据投毒、模型窃取、对抗攻击、API漏洞、供应链安全、Agent特定威胁等具体风险类别，并通过可视化图示（如“人工智能全生命周期安全风险全景图”）直观呈现风险分布。在此基础上，本文重点探讨将DevSecOps理念应用于AI安全治理的实践框架，即MLSecOps，评估其在应对AI特有风险中的价值与局限性，并结合全球主要经济体（欧盟、美国、中国）的监管趋势、人工智能的伦理考量以及日益凸显的地缘政治影响，勾勒出AI安全治理的复杂图景与未来方向，并借助可视化模型（如“应用于人工智能安全的MLSecOps治理模型”）阐述治理流程。最终，本文将提出应对AI安全挑战的高级防御策略与新兴技术，为构建安全可信的人工智能生态体系提供参考和启示。

1. 引言：AI的技术本质与固有的安全挑战

1.1. 人工智能：软件、数据与算法的融合与演进

人工智能并非单一的技术实体，而是现代信息技术要素——软件工程方法、海量数据处理技术和复杂算法理论——深度融合与演进的产物。这种融合构成了AI系统的核心特点。如图所示，AI系统建立在传统软件工程之上，但其功能实现和行为逻辑不再完全依赖预设的硬编码规则，而是通过复杂的算法（如神经网络）从海量数据中学习、提取模式并构建模型。数据成为驱动AI系统的关键要素，其规模、多样性、质量和时效性直接决定了模型的性能和能力边界。算法则是实现从数据中学习并进行推理、决策的核心引擎。

<svg width="600" height="300" xmlns="http://www.w3.org/2000/svg">
  <style>
    .box { fill: #4682B4; stroke: #000; stroke-width: 1; }
    .text { font-family: Arial, sans-serif; font-size: 16px; fill: #fff; text-anchor: middle; dominant-baseline: middle; }
    .arrow { stroke: #000; stroke-width: 1.5; marker-end: url(#arrowhead); }
    #arrowhead { markerUnits: strokeWidth; refX: 0; refY: 2; orient: auto; markerWidth: 10; markerHeight: 10; fill: #000; stroke: #000;}
  </style>
  <marker id="arrowhead" viewBox="0 0 10 4" refX="0" refY="2" markerUnits="strokeWidth" orient="auto" markerWidth="5" markerHeight="3">
    <path d="M 0 0 L 10 2 L 0 4 z" fill="#000"/>
  </marker>

  <rect class="box" x="50" y="100" width="120" height="50" rx="5" ry="5"/>
  <text class="text" x="110" y="125">软件工程</text>

  <rect class="box" x="240" y="100" width="120" height="50" rx="5" ry="5"/>
  <text class="text" x="300" y="125">数据处理</text>

  <rect class="box" x="430" y="100" width="120" height="50" rx="5" ry="5"/>
  <text class="text" x="490" y="125">算法模型</text>

  <rect class="box" x="240" y="200" width="120" height="50" rx="5" ry="5"/>
  <text class="text" x="300" y="225">人工智能</text>

  <line class="arrow" x1="170" y1="125" x2="240" y2="125"/>
  <line class="arrow" x1="360" y1="125" x2="430" y2="125"/>
  
  <line class="arrow" x1="110" y1="150" x2="260" y2="200"/>
  <line class="arrow" x1="300" y1="150" x2="300" y2="200"/>
  <line class="arrow" x1="490" y1="150" x2="340" y2="200"/>

</svg>

图1.1：人工智能的技术融合本质

这种固有的融合特性决定了AI安全风险的多源性。风险可能源于传统的软件代码漏洞，可能源于数据的质量、隐私和完整性问题，也可能源于算法本身的数学脆弱性或训练过程的缺陷。同时，这些不同来源的风险并非孤立存在，它们相互作用，形成复杂的安全挑战。例如，不安全的代码可能导致数据泄露，有偏见的数据可能导致算法输出歧视性结果，算法漏洞可能通过API暴露给外部攻击者。

近年来，以Transformer架构为核心的预训练大模型（例如GPT系列、BERT等）取得了革命性进展，其参数规模达到千亿甚至万亿级别，对海量训练数据的极致依赖（涵盖互联网几乎所有可公开获取的信息）以及极其复杂的分布式训练过程，同步引入了前所未有的安全挑战。这些模型的庞大规模和“黑盒”特性，使得其内部可能存在的漏洞、后门或偏见难以被有效检测和溯源。同时，这些模型作为基础模型（Foundation Model），一旦存在安全隐患，其负面影响会迅速通过模型复用和迁移学习扩散到众多下游应用场景，形成潜在的风险放大效应。

1.2. AI安全风险的内在复杂性与全生命周期特性

AI系统的安全风险具有内在复杂性和全生命周期特性。与传统信息系统相比，AI系统的安全风险不仅包含传统的软硬件和网络安全问题，更与AI特有的要素——数据和模型本身——紧密关联。这种关联使得AI安全风险具有以下特点：

• 数据依赖性风险： AI模型从数据中学习，数据中的任何问题（如偏见、错误、污染）都会直接影响模型的安全和性能。
• 算法脆弱性风险： 复杂的非线性算法模型可能存在数学或博弈层面的脆弱性，如容易受到对抗样本的欺骗。
• “黑盒”或“灰盒”风险： 深度学习模型的复杂性导致其决策过程难以完全解释，给漏洞发现、安全审计和责任追溯带来困难。
• 动态性与不确定性： AI系统通过学习和迭代不断演进，其行为可能随时间和环境变化，使得静态的安全评估难以提供持续保护。特别是生成式AI，其输出具有一定非确定性，增加了安全防护的难度。

这些风险并非只存在于某个特定环节，而是贯穿AI从概念到退役的整个生命周期。如图1“人工智能全生命周期安全风险全景图”所示，AI的安全挑战涵盖：

图1：人工智能全生命周期安全风险全景图

• 数据采集与准备阶段： 数据投毒、隐私泄露、偏见引入。
• 模型设计与开发阶段： 模型架构漏洞、算法选择风险、硬编码敏感信息。
• 模型训练阶段： 数据投毒的实际执行、后门植入、训练过程中的隐私泄露、训练环境安全。
• 模型验证与测试阶段： 发现对抗样本脆弱性、模型鲁棒性不足、偏见未检测。
• 模型部署阶段： 基础设施安全（物理、网络、云平台）、API安全、容器/虚拟化安全、配置错误。
• 模型运营与维护阶段： 持续对抗攻击、模型漂移导致的安全问题、服务滥用、日志与监控安全。
• AI应用与Agent阶段： 提示词注入、Agent行为风险、RAG系统漏洞、业务逻辑缺陷、供应链攻击（通过插件/依赖）。
• 模型退役阶段： 模型和数据安全销毁，防止泄露。

因此，构建一个覆盖AI全生命周期的、动态的安全治理体系显得至关重要。传统的、将安全视为开发后期“补丁”的做法，已经无法应对AI这种具有内生风险和快速迭代特性的系统。

1.3. 本文核心主题：AI安全风险剖析与DevSecOps治理框架探讨

基于对人工智能技术本质及其全生命周期风险特性的深刻认识，本文旨在提供一份全面、深入且基于最新研究成果的分析报告。我们将严格遵循先前制定的文章大纲，并充分利用所有相关的研究材料进行内容扩充和深化。

本文将首先在第二章系统性地剖析人工智能在不同生命周期阶段面临的核心安全风险，从数据准备、模型训练等预训练阶段的内生风险，到模型部署时的基础设施与API安全挑战，再到AI应用特别是Agent带来的新威胁。我们将对数据投毒（包括不同类型和最新手段如干净标签投毒）、模型窃取（深入分析攻击技术如S&W算法）、对抗攻击（原理、类型、影响）、API漏洞（结合OWASP API Security Top 10和具体案例如Ollama）、供应链安全（开源组件、第三方服务、AI-BOM）以及AI Agent特定威胁（提示词注入、知识库投毒、权限滥用）等具体风险类别进行详细阐述，并结合图1“人工智能全生命周期安全风险全景图”进行可视化呈现。

在第四章，本文将重点探讨将DevSecOps理念应用于AI安全治理的实践框架，即MLSecOps。我们将详细分析DevSecOps的核心原则（安全左移、自动化、持续集成/部署、持续监控、IaC、策略即代码、威胁建模、安全文化）如何适配AI/ML工作流，并构建MLSecOps治理模型，借助图2进行可视化说明，展示其在应对AI特有风险中的潜力、具体实践落地路径（如AI安全CI/CD流水线、AI特有工具链整合）以及与MLOps等其他框架的比较与融合。

图2：应用于人工智能安全的MLSecOps治理模型

在第五章，我们将把AI安全置于更广阔的背景下，分析全球主要经济体（欧盟、美国、中国）的AI监管框架与趋势（包括主要法规、风险分级、AIGC标识义务对比等）、人工智能带来的复杂伦理和社会挑战（算法偏见、隐私侵犯、对齐问题、虚假信息、就业影响、责任归属），以及AI技术日益凸显的地缘政治影响（战略技术竞争、关键基础设施风险、认知战）。这将有助于理解AI安全治理不仅是技术问题，更是涉及法律、伦理、国际关系等多维度的系统性工程。

最后，在第六章，本文将介绍当前的高级防御策略与新兴AI安全技术，包括AI红队测试、基于AI的安全检测、机密计算（Confidential AI）、AI护栏（Guardrails）、智能水印、知识链框架、深度伪造检测工具、工业级安全基准测试、AI安全评估平台等，并展望AI安全领域的未来研究方向和发展趋势（MLSecOps成熟、运行时安全、零信任、Agent/多模态安全、标准制定、人才培养、非确定性应对、多元协同机制）。

通过这种结构，本文力求全面、深入地分析人工智能安全风险，并为构建有效、可持续的AI安全治理体系提供有价值的参考和启示。

2. 人工智能全生命周期核心安全风险

人工智能系统的安全风险贯穿其从数据、模型到应用的完整生命周期。本章将根据AI生命周期的主要阶段，系统地剖析其核心安全挑战，并结合最新研究成果和具体案例进行深度分析。

2.1. 预训练模型阶段的内生安全风险

预训练模型是AI能力的基石，其安全风险主要源于数据、算法和复杂的训练工程。

2.1.1. 数据风险：预训练的基石与隐患

预训练模型的性能和行为高度依赖于大规模、多样化的训练数据集。然而，数据的来源、质量、处理方式以及数据本身的内容都可能引入严重的安全隐患。

• 数据投毒与污染： 数据投毒是指攻击者通过向用于训练或微调AI模型的数据集中注入少量精心构造的恶意或损坏样本（即“有毒数据”），从而操纵模型的学习过程和长期功能，损害模型的可用性、完整性或准确性。这种攻击旨在使模型中毒，导致其在实际应用中出现非预期的、通常是有害的行为。例如，在图像分类模型中，投毒样本可能是在特定物体的图片上添加一个微小的、人眼难以察觉的图案，使得模型在遇到带有这个图案的任何图片时都错误地将其分类为某个目标类别（如“武器”），即使原始图片是无害的。在文本生成模型中，投毒可能是在训练数据中混入少量包含特定关键词和恶意指令的文本对，使得模型在遇到关键词时生成攻击者预设的恶意内容。

  数据投毒的攻击目标多样，既可以是非针对性攻击，旨在降低模型的整体性能或使其输出无用结果（拒绝服务）；也可以是针对性攻击，旨在操纵模型在遇到特定“触发器”（trigger）时执行攻击者期望的恶意行为，从而在模型中植入后门（Backdoor）[^2, ^4]。攻击者可能希望通过后门攻击，在模型部署后，利用触发器远程激活模型的恶意功能，例如绕过安全检测、生成恶意代码、或泄露敏感信息。

  数据投毒可以在AI模型的预训练和微调（fine-tuning）阶段都产生影响[^1, ^4, ^5]。预训练阶段通常使用海量、来源广泛（如从互联网抓取）的数据，这使得对投毒数据的检测和过滤极为困难。微调阶段使用的数据量相对较小，但由于其通常是特定任务的高质量数据，投毒样本的影响可能更集中和显著。特别是大型语言模型（LLMs），其训练数据（如互联网公开数据、书籍、代码库等）和公开的预训练模型本身都可能包含投毒样本，例如开源模型库（如Hugging Face）中托管的模型可能被上传者植入后门^[1]。复杂的多阶段训练流程（预训练 -> 微调 -> 对齐训练）为投毒攻击提供了更多的入口和隐藏机会^[1:1]。

  具体的攻击机制和类型包括：

  • 标签翻转（Label flipping）：这是最简单但有效的投毒方式之一。攻击者修改训练样本的标签，例如将带有猫图片的标签改为“狗”。这会误导模型学习错误的类别边界^[2]。
  • 数据注入（Data injection）：攻击者向训练数据集中插入完全伪造的新数据点，这些数据点可能带有恶意的特征或标签，旨在将模型行为引导到攻击者期望的方向^[2:1]。
  • 后门攻击（Backdoor attacks）：如前所述，通过在训练数据中嵌入带有特定“触发器”的样本，使模型在遇到触发器时表现出恶意行为。例如，在图像识别中，触发器可以是一个小图案；在文本生成中，触发器可以是一个短语或关键词[^2, ^4, ^5]。开源模型因其可访问性，更容易成为后门攻击的目标[^2, ^3]。
  • 干净标签攻击（Clean-label attacks）：这是一种更高级且隐蔽的投毒方式[^2, ^4]。攻击者在保持训练样本原始正确标签不变的情况下，对样本的特征进行微小但关键的修改，植入后门或影响模型性能。由于标签是正确的，传统的数据清洗方法（如基于标签一致性进行过滤）难以检测这种攻击，隐蔽性极强^[3]。

  数据投毒的风险来源多样，可能来自不安全的第三方数据提供商、从不可信网站抓取的数据、被攻击的开源数据集仓库，甚至数据在内部传输或存储过程中的篡改[^2, ^4]。数据供应链安全问题，即数据从源头到最终被用于训练模型的整个过程中任何环节被污染，是数据投毒风险的一个重要层面[^1, ^4]。

  数据投毒的后果严重且多样：

  • 分类错误和性能降低： 导致模型在正常输入下也更容易出错，或整体性能（如准确率）下降^[3:1]。
  • 引入或放大偏见： 投毒数据可能加剧模型中的固有偏见或引入新的偏见，导致歧视性结果^[3:2]。
  • 为后续攻击打开通道： 被投毒的模型可能更容易受到对抗攻击或模型提取攻击的影响[^2, ^3]。
  • 执行恶意功能： 后门投毒可能导致模型在特定条件下执行有害操作，例如在对话系统中生成网络钓鱼链接，或在代码助手中生成带有漏洞的代码。

  值得区分的是，数据投毒和提示注入（Prompt Injection）虽然都涉及操纵输入，但作用阶段不同[^2, ^3]。数据投毒发生在训练阶段，影响模型学习到的长期功能和固有行为，是模型本身的“疾病”。提示注入发生在推理或应用阶段，操纵的是模型的即时输入提示，影响生成式AI系统的当次输出行为，是模型对“外部指令”的误解或劫持。数据投毒的影响是持久且隐蔽的，而提示注入的影响通常是即时的。

  缓解与防御数据投毒的策略是一个活跃的研究领域，主要包括：

  • 数据清洗与验证： 在训练前对数据进行异常检测，识别并过滤潜在恶意样本^[1:2]。可以使用统计方法、可视化分析或异常检测模型来标记可疑数据。
  • 数据来源管控与溯源： 限制使用非可信数据源，建立数据供应链的安全审查和审计机制^[1:3]。通过数据血缘追踪记录数据的来源和处理过程，有助于在发现问题时快速定位投毒源。
  • 鲁棒训练算法： 采用对抗训练、差分隐私或正则化等方法提升模型对投毒数据的鲁棒性^[1:4]。例如，一些方法尝试使模型对训练集中的少量异常样本不那么敏感。
  • 模型行为监控： 在模型部署后，持续监控模型的输入和输出行为，检测是否出现与投毒相关的异常模式^[1:5]。
  • 认证防御与不可学习性研究： 探索更根本的防御措施。例如，对RAG系统中被毒化的文本进行追溯（如RAGForensics）^[4]，或研究如何使投毒效果在模型训练中不可学习（Machine Unlearning的逆向应用）^[5]。

• 隐私泄露与敏感信息风险： 预训练模型，特别是大型模型，由于其庞大的参数量和强大的学习能力，可能在训练过程中**“记忆”训练数据中的敏感信息，如个人身份信息（PII）、商业机密、敏感文档内容等，并在推理时通过生成的文本、代码或其他行为无意或恶意地泄露这些信息**。即使用户向大模型输入的机密信息未被明确用于再训练，也可能被存储在对话历史中或间接影响模型的行为，构成潜在泄露风险^[1:6]。

  主要的隐私泄露攻击类型包括：

  • 成员推断攻击（Membership Inference Attacks, MIAs）：攻击者试图判断特定的数据记录（如某用户的文本输入、某张图片）是否包含在模型的训练集中。如果能够确定某个用户的敏感数据被用于训练模型，这本身就是一种隐私侵犯^[6]。
  • 数据提取攻击（Data Extraction Attacks）：攻击者通过精心构造的查询（Prompt），诱导模型“背诵”或重构训练数据中的具体内容。这可能导致模型的敏感训练数据被直接提取出来^[6:1]。
  • PII重构攻击（PII Reconstruction Attack）：这是数据提取攻击的一种特殊形式，专门针对训练数据中被脱敏或掩码的个人身份信息（如姓名、地址、电话号码）。攻击者试图恢复这些敏感实体^[6:2]。 最新研究进展中，R.R. (Recollect and Rank) 攻击由Wenlong Meng et al. (2025) 提出，这是一种两阶段的PII窃取攻击。首先通过“回忆 (recollection)”提示词诱导LLM填充掩码文本中的PII，然后利用基于损失的排序（可选参考模型校准）来识别最可能的PII。实验表明，即使训练数据经过脱敏（PII掩码），LLM仍易受此类攻击^[6:3]。大型代码模型 (LLMs4Code) 也存在记忆问题，可能泄露训练代码中硬编码的凭证等敏感信息^[7]。

  缓解与防御隐私泄露的策略包括：

  • 数据脱敏与匿名化： 在训练前对敏感信息进行处理，如移除或替换敏感标识符^[1:7]。
  • 差分隐私（Differential Privacy, DP）：在训练过程中加入精心计算的随机噪声，使得任何单个训练样本的加入或移除对最终模型的输出影响微乎其微，从而保护个体数据隐私[^1, ^25]。DP-SGD（差分隐私随机梯度下降）是在深度学习中应用DP的主要方法^[8]。然而，DP面临效用-隐私权衡（更强的隐私保护可能导致模型性能下降）、计算开销大、可扩展性不足以及经验性隐私评估与理论保证之间可能存在差距等挑战^[9]。最新研究包括PMixED等在推理阶段提供DP的方法^[8:1]，以及探索不同微调方法在DP约束下的隐私-效用权衡^[9:1]。
  • 机器不可学习（Machine Unlearning）：使模型“忘记”特定数据，作为一种有前景的缓解隐私泄露的方法，尤其在LLMs4Code中显示出有效性^[7:1]。
  • 访问控制和权限管理： 遵循最小权限原则，严格限制对训练数据和模型权重的访问^[1:8]。
  • 机密计算（Confidential Computing）： 在可信执行环境（TEE）中进行模型训练和推理，确保数据在处理过程中也是加密状态，防止云服务商或未授权方访问敏感数据^[10]。

  数据投毒和隐私泄露可以被视为预训练模型面临的“一体两面”的内生风险，均源于模型对训练数据的深度依赖和潜在的记忆效应。数据投毒利用模型从数据中学习的特性，通过恶意样本污染学习过程^[2:2]，而隐私泄露则是因为模型在学习过程中可能“过度”记忆了训练数据中的敏感细节^[6:4]。这两者共同揭示了模型训练过程对输入数据的内在脆弱性。因此，防御数据投毒的技术（如数据验证、鲁棒训练）和保护隐私的技术（如差分隐私、数据脱敏）需要协同考虑，避免在强化一方面时削弱另一方面。

• 数据供应链安全与可信来源： AI模型的训练数据通常来自多个源头，包括开源数据集、第三方数据提供商、网络爬取等，构成了一个复杂且多环节的“数据供应链”^[11]。这条供应链的任何环节都可能被污染或操纵，导致训练数据中包含恶意内容、偏见或不准确信息^[1:9]。

  风险点主要包括：

  • 第三方数据源污染： 购买或使用来自不可信第三方的标注数据集、图片集、文本语料库等可能包含投毒样本、错误标签或引入偏见^[1:10]。
  • 开源库或配置文件被污染： 在下载和使用开源数据集处理工具、数据加载库，甚至预训练模型本身或其配置文件时，可能遭受供应链攻击。例如，Hugging Face等模型库中托管的预训练模型和配置文件可能被篡改，上传者可能在其中植入后门或恶意脚本^[11:1]。最新研究揭示，模型配置文件也可能被利用执行未授权代码^[12]。
  • 数据传输过程中的篡改： 数据在不同环节之间传输时，如果通信通道不安全，可能被中间人攻击篡改。

  最新研究进展方面，Ziqi Ding et al. (2025) 的研究 (ConfigScan) 揭示了Hugging Face等AI供应链中配置文件被利用的风险，包括文件操作、网站操作和仓库操作风险，并开发了基于LLM的工具ConfigScan来检测恶意配置^[12:1]。AI SBOM (Software Bill of Materials) 或 AI-BOM (AI Bill of Materials) 扩展了传统SBOM的概念，用于记录AI模型的“成分”，包括数据集、算法、训练参数、依赖库等，以增强透明度和可追溯性^[13]。SPDX 3.0等标准开始支持AI-BOM的构建^[14]。然而，当前SBOM格式在精确指向数据集特定修订版方面存在不足，这对于追踪和管理受污染数据集训练的模型至关重要^[13:1]。Data Version Control (DVC) 等工具为此提供了潜在解决方案^[13:2]。

  缓解与防御数据供应链风险的策略包括：

  • 严格审查数据来源和第三方依赖： 对数据提供商进行尽职调查，审查其数据收集和安全实践。使用开源库时，验证其来源和完整性^[1:11]。
  • 使用AI-BOM/SBOM进行依赖项跟踪和漏洞管理： 维护AI系统的组件清单，持续监控这些组件的安全漏洞^[13:3]。
  • 对模型和配置文件进行安全扫描和验证： 在使用第三方模型或配置文件之前，使用Fickling、ModelScan、ConfigScan等工具进行安全扫描和验证，检测潜在的恶意内容或后门^[11:2]。
  • 采用零信任原则和移动目标防御（MTD）、内容解除和重构（CDR）等策略保护模型分发^[11:3]。限制对模型仓库的访问，对下载的模型进行额外的安全检查。

  AI数据供应链的复杂性和不透明性是当前AI安全治理的薄弱环节。AI模型，特别是大模型，其训练数据来源极其广泛，包括公开数据、爬取数据、第三方授权数据等，构成了一个复杂的供应链^[11:4]。虽然SBOM/AI-BOM的理念旨在提高透明度，但当前标准对数据集的描述能力有限，特别是缺乏对数据集版本、预处理过程、质量评估和已知偏见的标准化记录^[13:4]。这导致即使有了AI-BOM，也很难准确追溯某个模型版本是基于哪个具体版本、经过何种处理的数据集训练的。一旦发现数据集存在问题（如投毒、偏见、许可问题），将难以快速定位受影响的模型范围并采取有效措施。

• 数据质量、偏见与公平性挑战： 训练数据的质量直接影响模型性能。数据中的偏见（Bias），如历史偏见（反映历史社会不公）、表征偏见（某些群体在数据中代表性不足）、测量偏见（特征测量方式对不同群体有系统性误差）等^[15]，可能导致模型产生不公平或歧视性的输出，加剧社会不平等^[1:12]。例如，在招聘AI中，如果训练数据反映了过去性别或种族在特定职位的分布，模型可能习得这种模式，在筛选简历时无意识地歧视特定群体。在医疗AI中，如果训练数据主要来自特定人群（如白人男性），模型对其他人群（如女性、少数族裔）的诊断准确性可能较低，造成医疗资源分配的不公^[15:1]。数据质量问题，如标注错误、数据不一致、缺失值过多等，也会导致模型性能低下或行为异常。

  偏见类型多样，包括算法偏见、混淆偏见、内隐偏见、测量偏见、选择偏见、时间偏见等^[15:2]。它们可能在数据收集阶段（数据偏见）、模型开发阶段（算法偏见，如选择了不公平的算法或度量标准）或实施阶段（用户交互偏见，如用户如何与系统交互导致偏见）引入^[16]。

  最新研究进展中，G-AUDIT (Generalized Attribute Utility and Detectability-Induced bias Testing) 框架被用于检测医疗AI数据集中的偏见和捷径学习，通过量化属性效用和可检测性来识别潜在偏见源^[15:3]。此外，偏见感知知识检索利用Agentic框架和偏见检测器作为工具，识别和高亮检索内容中的固有偏见，以增强信息系统的公平性^[17]。公平性缓解技术包括预处理（如对数据进行重采样、重加权以平衡不同群体的样本）、处理中（如在训练损失函数中加入公平性约束，惩罚偏见）、和后处理（调整模型输出结果以满足公平性标准）等方法^[17:1]。

  缓解与防御数据偏见的策略包括：

  • 数据审计与偏见评估： 在模型训练前对数据集进行审计，识别和量化偏见^[15:4]。使用如AI Fairness 360、G-AUDIT等工具^[1:13]。
  • 多样化和代表性的数据收集： 确保训练数据能够准确代表目标人群和真实世界的多样性，避免因数据来源单一导致偏见^[1:14]。
  • 偏见缓解算法： 应用预处理、处理中或后处理技术来减轻已识别的偏见^[17:2]。
  • 透明度与可解释性： 提升模型决策过程的透明度，帮助理解和发现潜在偏见^[1:15]。当发现模型输出存在偏见时，可解释性技术有助于定位偏见来源是数据还是算法。
  • 建立伦理审查流程： 在AI项目早期引入伦理专家进行审查，评估潜在的偏见和社会影响。

  数据偏见不仅是一个技术问题，更是深层社会和伦理问题的映射。AI模型从数据中学习到的偏见往往反映了现实世界中存在的历史性、系统性不公^[15:5]。虽然技术手段如偏见检测工具（例如G-AUDIT^[15:6]）和缓解算法^[17:3]能够识别并在一定程度上减轻偏见，但“公平”的定义本身是多维度且高度依赖于具体情境的，不存在普适的、一劳永逸的公平性指标或技术解决方案^[16:1]。不同的公平性定义（如机会均等、结果平等、预测准确率均等）可能相互冲突。因此，解决AI偏见问题，除了持续的技术改进外，更需要跨学科的治理方法，包括但不限于伦理审查委员会的介入、多元化团队的参与、持续的社会影响评估以及相关法律法规框架的不断完善和演进。国际标准化组织（如ISO/IEC TR 24027）也在制定AI公平性相关的标准^[16:2]。

下表总结了本节讨论的主要数据风险及其缓解策略：

风险类别	风险描述	对预训练模型的影响	主要攻击向量/示例	主要缓解技术	相关研究/框架
数据投毒	恶意污染训练数据，导致模型学习错误行为或后门	模型完整性受损、性能下降、产生恶意输出、泄露信息	标签翻转、数据注入、干净标签攻击、目标模型投毒、后门攻击（通过触发器）	数据清洗与验证、数据来源管控、鲁棒训练算法、认证防御、异常检测	Xin Wang et al. (2025) (目标模型投毒)[18], Carlini et al. (2024) (LLM投毒)[19], RAGForensics (RAG投毒追溯)[4:1], OWASP LLM Top 10 (LLM04)[20]
隐私泄露	模型记忆并泄露训练数据中的敏感信息（如PII）	违反隐私法规、损害用户信任、暴露商业机密	成员推断攻击(MIA)、数据提取攻击、PII重构攻击(如R.R.攻击)	数据脱敏与匿名化、差分隐私(DP-SGD)、机器不可学习、访问控制、机密计算	Wenlong Meng et al. (2025) (R.R. Attack)[6:5], LLMs4Code隐私研究[7:2], Privacy in Large Language Models (Survey)[^26, ^64]
数据供应链污染	第三方数据源、开源库或配置文件被污染，引入恶意内容或漏洞	模型被植入后门、训练数据被污染、系统被控	Hugging Face恶意模型事件、恶意配置文件(如ConfigScan发现的)	严格审查数据来源和依赖、AI-BOM/SBOM、安全扫描(Fickling, ModelScan, ConfigScan)、零信任、MTD/CDR	ConfigScan[12:2], AI-BOM (SPDX 3.0)[^30, ^34], Cohen & Nissim (2025) (零信任/MTD/CDR)[11:5], OWASP LLM Top 10 (LLM05) (不安全供应链)[21]
数据质量与偏见	训练数据质量低下、标注错误、或包含系统性偏见，导致模型性能差或输出不公（算法偏差）	模型性能差、泛化能力弱、产生歧视性或不公平输出、加剧社会不平等	历史偏见、表征偏见、测量偏见在数据中的体现	数据审计与偏见评估(如G-AUDIT)、多样化和代表性数据收集、偏见缓解算法(预处理、处理中、后处理)、透明度与可解释性	G-AUDIT[15:7], Alashaikh et al. (2025) (偏见感知检索)[17:4], ISO/IEC TR 24027:2022 (公平性)[16:3], Diaz-Pinto et al. (2022) (执法领域偏见)[22]

表2.1: AI 预训练阶段的主要数据风险及其缓解策略总结

2.1.2. 训练算法的安全风险：

模型训练算法本身也可能成为攻击目标或引入安全隐患。这些风险通常利用了模型的数学原理和优化过程的特性。

• 算法漏洞与对抗性攻击： 对抗性攻击主要指在模型推理阶段，攻击者通过对输入样本添加人眼难以察觉的微小扰动，使得模型产生错误输出[^1, ^2]。例如，对一张熊猫的图片添加少量精心计算的噪声，可能使图片看起来仍像熊猫，但模型却将其错误分类为长臂猿。这种攻击的根源在于深度学习模型在高维输入空间中学习到的决策边界的脆弱性。在训练过程中，模型可能在数据点附近形成非常陡峭的决策边界，微小的扰动就能跨越这些边界，改变模型的预测。虽然对抗攻击主要发生在推理阶段（Evasion Attack），但其防御需要从训练阶段入手，提高模型的鲁棒性。

  除了规避攻击，算法层面还存在其他攻击类型：

  • 模型逆向攻击（Model Inversion Attack）：尝试从模型的输出（如预测概率、特征向量）中恢复输入数据的敏感信息，这与隐私泄露密切相关[^18, ^26]。例如，从面部识别模型的输出中重建出用户的面部图像。
  • 算法后门攻击（Algorithmic Backdoor Attack）：与数据投毒中的后门攻击类似，但可能通过修改训练算法或模型结构本身来植入后门，而不仅仅是依赖投毒数据^[23]。
  • 推理攻击（Inference Attacks）：包括成员推断攻击（判断数据是否在训练集中）^[6:6]、模型逆向攻击^[10:1]以及属性推断攻击（推断输入数据的某些敏感属性，如年龄、性别）。

  缓解这些风险的措施包括：

  • 对抗训练（Adversarial Training）：将对抗样本加入到训练集中，使模型在这些样本上也能给出正确预测，从而提升模型的鲁棒性^[1:16]。这是目前最有效的对抗防御方法之一。
  • 设计更鲁棒的模型架构：探索对对抗扰动不那么敏感的模型结构。
  • 采用梯度屏蔽或混淆技术：增加攻击者计算对抗样本所需的梯度信息的难度。
  • 对输入进行预处理或转换：如特征压缩、随机化等，以破坏对抗扰动^[1:17]。
  • 发展后门检测与移除技术：研究能够发现模型中是否存在后门以及如何安全移除的技术。BackdoorLLM^[23:1]是一个专门评估LLM后门攻击和防御的基准测试。

  这些算法层面的风险揭示了AI模型在数学和信息论层面上的固有脆弱性。仅仅依赖数据层面的防护是不够的，因为对抗性攻击利用了模型在高维空间中学习到的决策边界特性，而模型窃取则表明模型的输入输出行为本身就可能泄露其内部信息。这些问题与模型的数学原理、优化算法和信息表示方式紧密相关，因此需要从算法设计、模型架构和训练策略层面进行加固。特别是算法后门攻击，其隐蔽性和触发性对传统的基于输入输出的黑盒测试提出了严峻挑战，因为攻击者可以选择非常见或难以预测的触发器。传统的静态代码分析或网络流量分析也难以奏效，因为恶意逻辑嵌入在模型的权重参数中。因此，亟需研究能够探查模型内部激活模式、解释模型决策或进行特定触发器探测的新型检测技术。

• 模型窃取与逆向工程： 模型窃取是指攻击者试图非法复制或窃取训练好的AI模型。这可能通过向目标模型发送大量查询并根据输出训练一个替代模型（基于查询的窃取，黑盒）实现，或者通过直接访问存储模型文件的服务器或存储桶获取模型权重和结构（基于文件的窃取，白盒）^[1:18]。模型窃取攻击（Model Stealing Attack）是当前人工智能安全中极具威胁的一类攻击[^2, ^1]。

  模型窃取的攻击动机多样，既可能出于商业竞争，意图获取对手的核心AI能力和知识产权^[24]；也可能为了生成更有效的对抗样本，因为对目标模型的了解越多，生成的对抗样本越容易迁移到目标模型上^[3:3]。被窃取的模型还可能被用于开发恶意应用、进行二次投毒或作为进一步攻击的基础。

  攻击技术：

  • 基于查询的提取：这是最常见的模型窃取方式^[25]。攻击者通过向公开可用的模型API发送大量查询请求，记录输入和对应的模型输出（如预测类别、概率分布）。利用这些大量的输入-输出对，攻击者在本地训练一个替代模型（通常是一个较小的模型），使其尽可能地复制目标模型的行为。
  • 基于文件的窃取：如果攻击者能够突破目标系统的外围防御，访问存储模型文件的服务器或存储，就可以直接复制模型权重和结构。这通常需要结合基础设施漏洞利用或内部威胁。
  • S&W算法详细分析：最新研究中提出的S&W算法，显著提升了基于查询的模型窃取效率和替代模型性能^[3:4]。其核心创新在于：
    • 多样化的重要性采样策略（如k-Center）：传统的窃取方法可能随机选择查询样本，效率较低。S&W算法利用K-Means或k-Center等聚类算法，从无标签的公共数据集中选择具有代表性的样本进行查询，确保查询样本能够更好地覆盖目标模型的输入空间，捕获模型在不同数据分布上的行为特性^[3:5]。这种智能采样减少了所需的查询次数。
    • 加权差异损失函数：在训练替代模型时，S&W算法引入一个加权的损失函数。对于替代模型预测结果与目标模型差异较大的样本（即替代模型难以模拟的“难样本”），赋予更大的权重。这使得替代模型更加关注这些难以模拟的行为，从而更精确地复制目标模型的复杂决策逻辑，尤其是在对攻击者重要的区域^[3:6]。 实验证明，S&W方法在CIFAR10、MNIST等多个数据集上，替代模型与受害模型的功能相似度高达77.42%-98.90%，且生成的对抗样本迁移成功率提升14.48%以上^[3:7]。这表明即使模型结构不同，高效的查询窃取方法也能复制目标模型的关键功能。

  防御挑战在于： 区分合法用户查询与恶意窃取查询极为困难^[3:8]。简单的限速或基于IP的过滤容易被绕过。引入预测扰动（Prediction Poisoning）等防御方法可能影响模型的可用性和客户体验。高效的窃取算法，如S&W，能够模仿正常用户行为的统计特征（例如查询分布可能看起来自然），使得基于查询统计的检测方法失效^[3:9]。因此，需要更复杂的行为分析、基于模型的异常检测以及结合业务上下文的审计。模型结构和攻击策略选择对窃取效果影响显著，S&W算法在不同替代模型结构均表现稳健，且相似性波动小于其他方法，表明具有良好的适配性和实用价值^[3:10]。

  缓解模型窃取的措施包括：

  • 模型水印（Model Watermarking）：在模型参数中嵌入可识别的标记，以证明模型的所有权，用于追踪模型来源和证明窃取行为^[24:1]。
  • 访问控制与加密：严格控制对模型文件和API的访问，对模型文件进行加密和签名验证，确保在存储和传输过程中不被非法访问和篡改^[1:19]。
  • 差分隐私：训练具有差分隐私保护的模型，使得从模型输出中难以推断精确参数，增加窃取模型功能的难度。
  • API速率限制与监控：防止通过大量查询进行模型提取^[21:1]。结合行为分析，检测异常查询模式（如查询样本的多样性、查询速度、查询返回结果的统计特征）。
  • 模型混淆：使模型的结构和参数更难以理解和复制，但这通常会影响模型的性能或训练效率。
  • 使用机密计算（Confidential Computing）：在可信执行环境（TEE）中运行模型推理服务，确保模型权重和推理过程不被外部环境访问^[10:2]。

• 后门攻击：后门植入机制（训练阶段）、触发器设计、对模型行为的隐蔽性影响、检测方法。 后门攻击通常发生在训练阶段，攻击者通过数据投毒（如在训练数据中添加带有特定触发器的样本）或修改训练过程，使模型在遇到特定的“触发器”（如图像中的一个像素点模式、文本中的一个短语、特定风格的图像）时，执行攻击者预设的恶意任务，而在正常输入下表现正常[^2, ^4, ^5]。触发器设计精妙，通常难以察觉（如一个像素、一个不常用词），保证了后门的隐蔽性[^2, ^5]。攻击者可以在模型发布后，通过向模型输入带有触发器的内容来激活后门，例如诱导文本生成模型生成钓鱼邮件，或在图像识别模型中将带有触发器的任何图片都识别为目标类别（如将所有带触发器的图片都识别为“允许进入”）。后门的影响具有持久性和针对性。

  检测后门是重要挑战，方法包括：

  • 检测训练数据中的异常模式：识别可能包含触发器或异常标注的样本，但这对于干净标签攻击无效。
  • 分析模型的内部激活模式：后门触发器通常会引起模型内部神经元独特的激活模式，可以尝试检测这些模式。
  • 行为测试（Behavioral Testing）：通过生成带有各种潜在触发器的输入来测试模型行为，观察模型是否表现出预设的恶意功能。BackdoorLLM^[23:2]是一个专门用于评估LLM后门攻击和防御的基准测试，提供了多种后门攻击和防御方法的实现。

  这些算法层面的风险揭示了AI模型在数学和信息论层面上的固有脆弱性。仅仅依赖数据层面的防护是不够的，因为对抗性攻击利用了模型在高维空间中学习到的决策边界特性，而模型窃取则表明模型的输入输出行为本身就可能泄露其内部信息。这些问题与模型的数学原理、优化算法和信息表示方式紧密相关，因此需要从算法设计、模型架构和训练策略层面进行加固。特别是算法后门攻击，其隐蔽性和触发性对传统的基于输入输出的黑盒测试提出了严峻挑战，因为攻击者可以选择非常见或难以预测的触发器。传统的静态代码分析或网络流量分析也难以奏效，因为恶意逻辑嵌入在模型的权重参数中。因此，亟需研究能够探查模型内部激活模式、解释模型决策或进行特定触发器探测的新型检测技术。

• 算法可解释性与透明度：理解模型决策过程对发现算法漏洞的重要性。 提高算法的**可解释性（Interpretability）和透明度（Transparency）**对于发现和理解算法层面的安全漏洞至关重要^[1:20]。可解释性是指理解模型为什么做出某个决策的能力，透明度是指了解模型的内部工作机制（如模型结构、训练数据、训练过程）的程度。如果能够理解模型为什么将某个对抗样本错误分类，或者为什么在遇到某个触发器时执行特定行为，就有可能发现其决策过程中的偏见、对抗样本的影响或后门的存在。XAI（Explainable AI）技术，如局部可解释模型无关解释（LIME）、SHapley Additive exPlanations（SHAP）、或者注意力机制可视化，有助于揭示模型的内部工作机制，为安全分析和漏洞发现提供洞察。例如，通过SHAP值分析输入特征对模型输出的贡献，可以发现模型是否过度依赖某些不应依赖的特征（如背景中的触发器），从而识别潜在的后门。可解释性也有助于审计模型的公平性，理解模型是否基于敏感属性（如种族、性别）进行决策^[1:21]。

  风险类别	风险描述	对模型的影响	主要攻击技术/示例	主要缓解技术
  算法漏洞	模型数学或优化过程中的脆弱性	易受攻击，性能不稳定	对抗性攻击（规避攻击）、模型逆向攻击、推理攻击	对抗训练、鲁棒模型架构、输入预处理、梯度屏蔽
  对抗性攻击	微小输入扰动导致模型输出错误	模型预测不准确，在安全关键场景带来风险	FGSM, PGD, C&W攻击；针对LLM的文本对抗样本	对抗训练、鲁棒模型架构、差分隐私、输入去噪、模型集成
  模型窃取	攻击者非法复制或窃取模型功能或参数	知识产权损失，可用于二次攻击（迁移攻击）	基于查询的窃取（如S&W算法）、基于文件的窃取	模型水印、访问控制与加密、差分隐私、API速率限制与监控、机密计算
  后门攻击	在训练阶段植入隐藏触发器，特定输入下执行恶意行为	模型行为可被攻击者远程操纵，且隐蔽性强	基于数据投毒的后门、算法层面的后门；图像触发器、文本触发器	数据集检测、模型行为测试、内部激活分析、后门移除技术、BackdoorLLM基准测试
  可解释性不足	难以理解模型决策过程	难以发现和诊断算法漏洞、偏见、后门；降低模型可信度	隐蔽的算法偏见、难以追踪的后门触发原因、对抗样本为何奏效的原因不明	XAI技术（LIME, SHAP等）、注意力可视化、透明度设计原则

  表2.2: AI 预训练阶段的主要算法风险及其缓解策略总结

2.1.3. 预训练复杂工程的集成风险：

预训练大模型通常涉及复杂的软件栈、硬件集群和分布式计算环境，这些工程层面的因素也可能引入安全风险。

• 软件与依赖库安全： AI模型的开发和训练依赖大量的开源库（如TensorFlow, PyTorch, Hugging Face Transformers, scikit-learn等）和第三方工具。这些依赖项可能存在已知或未知的漏洞，攻击者可以利用这些漏洞来破坏训练过程、窃取数据或模型，或植入恶意代码^[1:22]。这本质上是软件供应链攻击的一部分。

  具体风险包括：

  • 已知漏洞：使用的开源库版本存在已知的CVE漏洞，未及时更新或打补丁。
  • 恶意依赖：攻击者在流行的开源库中植入恶意代码，通过正常的依赖管理流程（如pip install, conda install）将其传播到AI训练环境中。
  • 被篡改的安装包：开源库的官方下载源或镜像站被攻击，安装包被植入恶意代码。
  • 模型文件/配置文件的恶意内容：如前所述，Hugging Face等模型库中托管的模型文件或配置文件可能被上传者植入恶意脚本，这些脚本可能在模型加载或使用时执行，例如执行任意命令、下载恶意负载、窃取敏感信息[^29, ^31]。ConfigScan等工具已被开发用于检测Hugging Face等AI供应链中的恶意配置文件风险^[12:3]。

  缓解措施包括：

  • 软件成分分析（SCA）：自动化扫描代码和依赖库，识别已知的开源组件并检测其已知漏洞^[1:23]。
  • 漏洞扫描与管理：定期对AI开发和训练环境中使用的所有软件进行漏洞扫描，并建立有效的漏洞管理流程^[1:24]。
  • 安全的CI/CD流水线：在CI/CD流程中集成自动化安全检查，确保只有通过安全验证的依赖库和代码才能被用于构建和训练^[1:25]。
  • 最小化依赖和沙箱隔离：尽可能减少不必要的依赖库；在沙箱或受限环境中运行潜在风险的依赖或代码。
  • 对第三方模型和配置文件进行安全扫描：在使用从外部获取的模型文件或配置文件之前，使用专门工具进行安全检查[^29, ^31]。
  • 构建AI物料清单（AI-BOM）：追踪所有依赖项，增强供应链透明度[^30, ^34]。

  AI预训练的复杂工程环境使其成为传统IT安全风险和AI特有风险的交汇点。攻击者可能利用传统软件漏洞（如操作系统漏洞、网络服务漏洞）来间接触发AI模型的安全问题。这意味着AI安全不能仅仅关注模型和数据，还必须覆盖整个训练和开发环境的纵深防御。预训练依赖于复杂的软件栈和硬件基础设施^[26]，这些传统IT组件本身就存在漏洞被利用的风险。攻击者可能首先攻陷底层基础设施或软件依赖，然后以此为跳板，篡改训练数据、窃取模型参数，或在训练环境中植入恶意代码，从而间接地对AI模型本身造成安全威胁。

• 大规模训练过程中的运营安全： 大模型训练通常在大型GPU/TPU集群上进行，涉及复杂的作业调度、数据传输和存储管理^[26:1]。运营过程中的配置错误、访问控制不当、监控不足等都可能导致安全事件。

  具体风险包括：

  • 网络配置不当：训练集群的网络配置过于开放，导致敏感数据或模型参数在内部网络中泄露；或者训练节点可以直接访问互联网，成为攻击者的跳板。
  • 访问控制不足：对训练集群的计算资源、存储系统、日志服务器等的访问权限管理不严，导致未授权用户或攻击者可以访问、修改或删除训练数据、模型权重或日志。
  • 监控与审计缺失：缺乏对训练作业、计算资源、数据访问等的有效监控和日志审计，无法及时发现异常行为或安全事件。
  • 分布式训练的攻击面：分布式训练的特性（如数据并行、模型并行、参数服务器）引入了新的攻击面和安全管理难点^[2:3]。分布式训练涉及多个计算节点之间的数据和模型参数的频繁通信和同步。节点间的通信信道、参数服务器的安全性、数据分片的管理和同步机制等都可能成为新的攻击点。例如，攻击者可能嗅探节点间通信窃取梯度信息，或攻击参数服务器篡改全局模型。
  • 敏感信息泄露：训练作业的日志记录不当可能泄露超参数、训练进度、数据集路径等敏感信息。

  缓解措施包括：

  • 基础设施即代码（IaC）与策略即代码：使用IaC工具（如Terraform, CloudFormation）自动化、标准化地部署和管理训练环境的基础设施，确保安全配置的一致性^[1:26]。通过策略即代码定义并强制执行安全策略，如网络隔离规则、访问控制策略。
  • 严格的身份与访问管理（IAM）：对所有访问训练资源的实体（用户、服务账号）实施最小权限原则，使用强认证机制（如MFA）^[1:27]。
  • 安全监控与日志审计：部署全面的监控和日志系统，实时监控训练集群的资源使用、网络流量、数据访问等，并对日志进行审计，检测异常行为^[1:28]。
  • 数据静态与传输加密：对存储在训练集群中的数据（如训练数据集、模型检查点）进行静态加密，对节点间或节点与存储系统间传输的数据进行传输加密^[1:29]。
  • 物理安全（针对本地部署）：保障数据中心的物理安全，防止未授权的物理访问^[26:2]。
  • 针对分布式训练架构的安全设计：针对分布式训练的特点，设计专门的安全策略，如节点身份认证、通信加密、参数服务器加固等。

  大规模分布式训练的特性（如数据并行、模型并行、参数服务器）引入了新的攻击面和安全管理难点^[2:4]。管理大规模集群的访问控制、安全配置和监控本身就是一项复杂任务，更容易出现疏忽和配置错误。因此，需要针对分布式训练架构设计专门的安全策略，如节点身份验证、通信加密、参数服务器加固等。同时，需要注意AI加速硬件（GPU/TPU）引入的新安全考量^[26:3]，如硬件漏洞、固件安全以及在共享环境中（如容器）的隔离问题。

2.1.4. 隐私增强技术在预训练中的应用与挑战

为了缓解预训练模型带来的隐私泄露风险，学术界和工业界正在积极探索和应用各种隐私增强技术（PETs）。PETs旨在允许在保护数据隐私的前提下进行数据分析或模型训练。

• 差分隐私（Differential Privacy, DP）： DP通过在数据处理或模型训练过程中引入经过精心计算的随机噪声，使得攻击者无法从最终输出结果中准确推断任何单个个体的数据是否存在或对结果产生了多大影响，从而提供可量化的隐私保护[^1, ^25]。DP-SGD（差分隐私随机梯度下降）是在深度学习中应用DP的主要方法，通过在计算和聚合梯度时添加噪声来实现隐私保护^[8:2]。 然而，DP面临的主要挑战在于效用-隐私权衡：更强的隐私保护（通常由隐私预算ϵ表示，ϵ越小隐私保护越强）往往意味着需要在数据中添加更多的噪声，可能导致模型性能（效用）显著下降[^20, ^27]。此外，DP-SGD的计算开销大，特别是在训练大型模型时。可扩展性不足以及经验性隐私评估与理论保证之间可能存在差距也是DP的应用挑战[^20, ^25]。最新研究包括PMixED等在推理阶段提供DP的方法^[8:3]，以及探索不同微调方法在DP约束下的隐私-效用权衡^[9:2]。

• 联邦学习（Federated Learning, FL）： FL是一种分布式机器学习范式，允许多个参与方（如用户的移动设备、不同机构的服务器）在本地使用其私有数据协同训练一个共享模型，而无需将原始数据发送到中央服务器[^1, ^65]。参与方只上传模型更新（如梯度或模型参数）到服务器进行聚合。这在保护数据本地性方面具有显著优势，尤其适用于医疗、金融等敏感数据领域，避免了数据集中带来的隐私风险[^24, ^62]。 然而，FL也面临挑战：

  • 通信开销大：尤其是对于大型模型，每次上传模型更新的通信量巨大，成为训练瓶颈^[10:3]。
  • 数据异构性（Non-IID数据）：不同参与方的数据分布可能差异很大，导致模型聚合困难，影响全局模型性能^[27]。
  • 模型更新泄露隐私：尽管不上传原始数据，但通过分析参与方上传的模型更新，攻击者仍可能推断出有关本地数据的敏感信息^[10:4]。
  • 系统异构性与可扩展性：参与方的计算能力、网络条件差异可能很大，影响训练效率和可扩展性^[28]。
  • 模型效用可能不及中心化训练。 FL通常用于对预训练的基础模型进行微调^[27:1]。最新研究包括将参数高效微调（PEFT）技术（如LoRA、DropPEFT^[29]）、知识蒸馏（KD）、分裂学习（SL）^[27:2]、Layer-Skipping FL^[30]等与FL结合，以减少通信开销和提高效率。同时，在FL中应用差分隐私^[31]和机器不可学习技术^[28:1]以增强隐私保护。

• 同态加密（Homomorphic Encryption, HE）： HE是一种密码学技术，它允许第三方（如云服务商）直接对加密数据进行计算，得到的计算结果解密后与对明文数据进行相同计算的结果一致[^1, ^70, ^71]。这意味着可以在不解密敏感数据的情况下对其进行处理，从而提供强大的隐私保护。HE为在不暴露原始数据的情况下进行模型训练或推理提供了可能性，例如用户可以将加密的查询发送给云上的加密模型进行推理，得到加密的结果，然后在本地解密。 然而，当前全同态加密（FHE）的计算成本非常高昂，对于大型语言模型等大规模模型，其实用性受到极大限制^[32]。实现复杂性高和支持的运算类型有限（某些HE方案只支持加法和乘法）也是挑战^[33]。HE可用于隐私保护机器学习（PPML）和联邦学习中的安全聚合，例如对参与方上传的模型更新进行加密聚合，防止聚合服务器看到单个参与方的更新^[31:1]。最新研究包括选择性加密（如FAS技术^[31:2]）以及与DP、安全多方计算（SMPC）等技术结合，以提高效率或增强功能^[31:3]。

  隐私增强技术	原理	优势	挑战	主要应用场景
  差分隐私(DP)	添加噪声模糊个体信息	可量化的隐私保护，适用于中心化和分布式场景	效用-隐私权衡、计算开销大、可扩展性、经验性评估难题	数据发布、模型训练(DP-SGD)、推理阶段的解释生成
  联邦学习(FL)	数据不出本地，只交换模型更新	保护数据本地性，适用于多方数据协作	通信开销大、数据异构性、模型更新泄露隐私风险、系统异构性	跨机构数据协作训练、用户设备上的模型微调
  同态加密(HE)	直接对加密数据进行计算	理论上提供最高级别隐私保护（密文计算）	计算开销极高（特别是FHE）、实现复杂、支持运算有限	安全聚合、隐私保护推理、数据加密存储后的计算

  表2.3: 隐私增强技术在AI预训练中的应用与挑战总结

  隐私增强技术（PETs）在AI预训练中的应用尚处于探索阶段，普遍面临着在模型效用、计算/通信开销和隐私保护强度之间的“不可能三角”困境^[33:1]。差分隐私虽然提供了可量化的隐私保证，但通常以牺牲模型效用和增加计算开销为代价[^20, ^25]。联邦学习旨在保护数据本地性，但仍存在模型更新泄露隐私的风险，并面临通信瓶颈和数据异构性的挑战^[10:5]。同态加密理论上能实现安全的密文计算，但其高昂的计算成本使其在LLM预训练等大规模场景下难以实用^[32:1]。目前，没有一种PET能够完美地同时实现强隐私保护、低开销和无损模型效用。实际应用中往往需要在这些目标之间进行权衡和折衷，或者采用多种技术组合的混合方法。

  此外，PETs的有效性不仅取决于技术本身，还高度依赖于具体的应用场景、设定的威胁模型以及与其他安全措施的协同部署。例如，联邦学习在数据不出域方面具有优势，但如果攻击者能控制部分客户端或服务器，仍可能通过分析模型更新来推断隐私信息；此时，需要结合差分隐私来增强保护^[31:4]。差分隐私的隐私预算$ϵ$的选择，需要根据数据的敏感性和可接受的风险水平来审慎确定，缺乏统一标准。同态加密的安全性则依赖于底层密码体制的强度和密钥管理的安全性。因此，不能孤立地看待PETs，而应将其视为纵深防御体系的一个组成部分，并根据具体需求进行定制化设计和部署。

  针对LLM的PETs研究，未来需要更加关注其特有的多阶段训练过程（预训练、微调、对齐）和日益多样化的数据类型（文本、代码、图像、音频等多模态数据）。LLM的训练是一个复杂的多阶段过程^[2:5]，每个阶段的数据来源、敏感性和面临的隐私威胁可能各不相同。例如，预训练数据量巨大但可能包含大量公开信息，而微调数据量相对较小但可能高度敏感。PETs的应用策略应针对不同阶段的特性进行优化[^20, ^65]。同时，LLM处理的数据类型日益多样化，从纯文本到代码^[7:3]，再到图像、音频等多模态数据。不同数据类型的隐私特征和保护需求各异，需要发展能够适应多模态数据特性的PETs^[34]。现有的PETs研究更多集中在传统机器学习模型或特定任务上，针对LLM全生命周期和多模态特性的研究仍有待加强。

2.2. 部署阶段的安全风险

模型训练完成后，需要部署到各种环境中提供服务，这包括私有化部署和云服务部署。部署环境的多样性和复杂性引入了新的安全挑战，将模型的内生风险暴露给更广泛的网络和用户，同时引入了基础设施和访问控制等层面的风险。

2.2.1. 私有化部署：基础设施安全风险

私有化部署指将AI模型及其运行环境部署在组织自有的或严格控制的基础设施内。这种模式的核心动因通常是数据安全、可控性和灵活性，尤其是在涉政、涉密、敏感信息以及对性能、成本有特殊要求的场景下[^1, ^3, ^62]。虽然看似能更好地控制数据，但也面临独特的安全挑战，并且安全责任几乎完全由组织自身承担。

私有化部署的主要安全风险包括：

• 基础设施“裸奔”： 近期研究显示，近90%的私有化部署服务器存在“裸奔”现象^[1:30]。这指的是服务器缺乏基础安全配置，如未设置防火墙、默认端口开放、未禁用不必要的服务、缺乏入侵检测/防御系统等，直接暴露在互联网上，极易遭受扫描和攻击。这种疏忽是导致私有化部署环境脆弱不堪的主要原因。
• 核心资产泄露： 由于基础设施防护薄弱或配置不当，攻击者一旦突破外围防御，就可能非法获取、恶意窃取、污染或毁坏私有化环境中的模型参数、训练数据、知识库及其他核心资产^[1:31]。这些资产往往价值巨大，泄露将带来严重经济和声誉损失。
• 服务瘫痪/中断： 基础设施的漏洞或攻击（如DoS攻击）可能导致模型推理能力瘫痪、计算资源被滥用（如被用于挖矿），最终造成服务中断，影响业务连续性^[1:32]。
• 开源依赖与第三方组件风险： 在私有化环境中构建和部署AI系统通常依赖大量的开源框架和第三方组件[^1, ^62]。如果安全意识薄弱，忽视这些组件的安全风险（如已知漏洞、潜在后门），或者在使用过程中未采取隔离和访问控制，就可能助长数据泄露及潜在的后门植入^[1:33]。
• 数据安全： 私有化部署AI大模型需要处理海量（含敏感/涉密）数据。如果数据的存储、传输或本地加密管理不当，极易洩漏用户隐私或商业机密^[1:34]。这包括数据库的访问控制不严、数据文件未加密、数据传输未走加密通道等。
• 内部威胁与物理/运维安全： 相较于云服务，私有化部署更容易受到内部威胁的影响[^1, ^78]。数据中心物理入侵、内部人员（员工、承包商）的疏忽、恶意或被胁迫行为（如滥用权限、窃取数据、植入恶意代码）都可能对私有化AI系统造成严重威胁[^1, ^78, ^79]。传统的物理安全（门禁、监控）、运维安全（堡垒机、日志审计）以及UEBA（用户和实体行为分析）^[35]等措施至关重要。
• 智能体（Agent）与知识库风险： 在私有化环境中部署的AI Agent，如果与企业内部关键系统、数据库、知识库深度集成，其潜在的漏洞或被控风险将更加严峻^[3:11]。攻击者一旦攻陷Agent，可能利用其高权限访问并操纵企业核心资产，引发一系列连锁物理或业务风险^[3:12]。RAG系统在私有化部署时，其知识库的保护和Agent访问知识库的控制尤为关键。
• API攻击： 无论是提供推理服务的API还是管理模型的API，都面临被攻击的风险，如前述的模型窃取、对抗性攻击、未授权调用等^[1:35]。
• 安全治理体系不足： 部分组织在安全治理体系建设方面滞后，管理者和员工安全意识薄弱、安防教育缺失，也是当前私有化部署面临的重大短板^[1:36]。缺乏全面的安全策略、流程和人员能力，使得即使部署了部分安全技术也难以形成有效的整体防线。

私有化部署将安全责任更多地从云服务商转移到组织自身[^1, ^62]。虽然这提供了更大的控制权，但也同时放大了组织在内部管理和运营能力方面可能存在的短板所带来的风险。云服务提供商通常具备成熟的安全基础设施和专业的安全团队^[36]，而私有化部署则需要组织自行构建和维护这些能力。如果组织在物理安全、网络安全、硬件安全、内部威胁防护、安全运维等方面投入不足或能力不足，私有化部署反而可能比使用安全的云服务面临更大的安全风险。

针对私有化部署，需要构建全链路安全体系^[3:13]，不仅关注模型本身的安全，也关注其运行的物理和网络环境、管理和运维流程、以及与之交互的其他系统。

2.2.2. 云服务：API风险、企业数据风险

将AI模型部署到云平台（如AWS, Azure, GCP）提供了便利性和可扩展性，但也带来了独特的安全挑战，尤其是在API接口安全和企业数据在云端的安全方面。在云环境下，安全责任遵循“共享责任模型”^[1:37]，用户需要理解自身在安全配置和管理方面的职责。

• API接口安全风险： AI模型通常通过API接口（如RESTful API）向应用提供服务（如推理、Embedding生成、模型管理）。这些API接口面临传统Web API的安全风险，同时也有AI特有的攻击向量。

  • 传统API风险： 认证授权缺陷、注入（如通过API传递恶意Prompt）、API滥用（如通过大量低价值查询消耗资源或进行模型窃取）、未授权访问敏感业务流（如模型管理功能）等[^1, ^83]。OWASP API Security Top 10中的多个风险类别直接适用于AI模型API，包括：

    • API1:2023 Broken Object Level Authorization (BOLA)：AI模型API可能暴露按对象ID（如模型ID、数据集ID、用户ID）访问的资源。若授权检查不当，攻击者可操纵ID访问未授权的模型或数据。例如，用户可能通过修改API请求中的model_id参数来访问或管理另一个用户的私有模型或获取其训练数据的信息^[37]。
    • API2:2023 Broken Authentication：AI模型API的认证机制（如API密钥、OAuth令牌）若实施不当，易被绕过或窃取，导致未授权访问[^1, ^95]。静态API密钥如果管理不善或传输不加密，极易泄露。
    • API3:2023 Broken Object Property Level Authorization：API未能对对象属性级别进行细粒度授权，可能导致敏感模型元数据（如训练数据描述）、配置或训练参数泄露^[37:1]。
    • API4:2023 Unrestricted Resource Consumption：AI推理API（特别是LLM）通常计算密集，若无速率限制和配额管理，易遭受DoS攻击（通过大量请求使服务过载）或导致运营成本飙升^[1:38]。
    • API5:2023 Broken Function Level Authorization：AI管理API中，若对不同功能（如模型训练、部署、删除）的权限控制不清，低权限用户可能越权执行高权限操作^[37:2]。
    • API7:2023 Server Side Request Forgery (SSRF)：如果AI模型API允许用户提供URL作为输入（例如，用于从外部获取数据进行分析或RAG系统中指定文档源），且未对URL进行严格验证，可能导致SSRF攻击，使服务器向内部或外部任意地址发起请求^[37:3]。例如，一个RAG系统的API接收用户提供的文档URL，若未校验，攻击者可提供指向内部敏感服务的URL。

  • AI特有API风险： 模型窃取（通过API查询）[^1, ^2]、对抗性攻击通过API输入以欺骗模型^[1:39]。攻击者可以利用API接口发送大量精心构造的输入，探测模型行为，以训练替代模型或生成对抗样本。

  • 具体漏洞（以Ollama为例）： 近期在Ollama框架中发现了六个漏洞^[3:14]，包括CVE-2024-39719, CVE-2024-39720, CVE-2024-39721, CVE-2024-39722等。这些漏洞可能导致身份验证失败、数据泄露、未授权访问、API滥用、输入验证不足、拒绝服务（DoS）攻击。特别严重的是，其模型管理端口（/api/pull和/api/push）缺乏认证控制，允许未授权的模型拉取或推送，可能导致模型污染或窃取专有模型资产^[3:15]。这表明即使在开源框架中，基础API安全实践也可能被忽视。

  防护策略： 针对AI模型API，需要采用比传统API更严格和针对性的安全措施，参考并扩展OWASP API Security Top 10的缓解建议：

  • ** 강화身份认证 (Strengthen Identity Authentication)**: 使用标准认证机制如OAuth 2.0, OpenID Connect, JWT，并强制执行多因素认证（MFA）以增强安全性[^1, ^82]。避免使用简单的静态API密钥。
  • 加密传输 (Encrypt Transmission): 确保所有API请求和响应均使用HTTPS等安全协议加密，防止数据在传输过程中被拦截^[1:40]。
  • 实施细粒度权限控制 (Implement Fine-Grained Permission Control): 使用基于角色的访问控制（RBAC）或其他机制为不同用户和角色定义不同的API访问权限，遵循最小权限原则^[1:41]。对模型管理、训练、推理等不同功能进行隔离和精细授权^[37:4]。
  • 监控与限流 (Monitoring and Rate Limiting): 实施严格的API调用频率限制和配额管理，防止资源滥用和DoS攻击^[1:42]。实时监控API使用模式。APIPark等平台提供详细的统计报告，用于分析API使用情况和检测异常调用模式（如大量查询、异常输入模式、查询多样性低等），显著提升API安全性^[1:43]。
  • 输入验证与过滤 (Input Validation and Filtering): 对所有用户输入进行严格验证和净化，特别是对于可能被用于提示词注入、对抗攻击或SSRF的输入[^1, ^83]。使用白名单策略控制输入格式和内容，过滤恶意代码或攻击载荷。对LLM的Prompt进行清洗和安全检查^[38]。
  • 输出过滤与审核：对于生成式AI模型API，对模型的输出进行过滤和审核，检测是否包含有害内容、敏感信息或与业务不符的输出，例如利用AI护栏（Guardrails）来实现^[3:16]。
  • 应用安全测试 (Application Security Testing): 定期进行安全测试，包括渗透测试、API模糊测试、代码审计，在部署前识别和修复潜在漏洞^[1:44]。参考NIST SP 800-228《云原生系统API保护指南》草案构建全面的API安全框架[^84, ^91]。

• 企业数据在云端的安全风险： 企业将敏感或专有数据上传到云端用于模型训练、微调或检索增强生成（RAG）时，面临数据泄露和未授权访问的风险^[1:45]。**数据驻留合规（Data Residency Compliance）**问题也需谨慎处理，尤其是在跨国公司或受严格数据主权法规管辖的行业^[1:46]。不同国家和地区对数据存储位置、处理方式有严格要求，企业需要确保所选的云区域和AI服务符合相关法规。

  具体风险点包括：

  • 云存储配置不当： 如S3存储桶配置为公开可访问，或权限过于宽松。
  • 数据传输过程中的泄露： 数据从企业本地上传到云端，或在云内部服务间传输时，如果未使用加密通道，可能被中间人攻击拦截。
  • 云服务提供商内部风险： 虽然云服务商有严格的安全控制，但理论上存在内部人员或系统漏洞导致数据泄露的风险。
  • 多租户环境下的隔离问题： 在多租户云环境中，虽然有隔离技术，但需警惕潜在的隔离绕过风险。

  缓解措施包括：

  • 数据加密： 对存储在云端的数据进行静态加密（Encryption at Rest），使用云服务商提供的加密服务或客户管理的加密密钥（CMK）增强控制[^53, ^106, ^107]。对数据从本地上传到云端、以及在云内部服务间传输时使用传输加密（Encryption in Transit），如TLS/SSL[^53, ^119]。
  • 身份与访问管理（IAM）： 精细化控制对云端数据资源的访问权限^[39]。遵循最小权限原则，只授予AI服务和用户完成任务所需的最低权限。定期审计IAM策略。
  • 数据丢失防护（DLP）： 在云环境中部署DLP策略，监控和防止敏感数据从云存储、虚拟机或其他服务中泄露^[1:47]。
  • 安全配置审计： 定期审计云资源配置，使用云安全态势管理（CSPM）工具自动检测和修复配置错误，确保符合安全基线和合规要求^[40]。
  • 虚拟私有云（VPC）与私有连接： 将AI服务部署在VPC内，并使用VPC端点或私有连接访问其他云服务，避免流量暴露在公共网络上^[41]。
  • 可信执行环境（TEE）/机密计算： 在云端使用TEE保护正在使用中的数据和模型，特别适用于处理高度敏感数据^[10:6]。

  各大云服务商如AWS (SageMaker^[39:1])、Azure (Azure ML^[42]) 和Google Cloud (Vertex AI^[40:1]) 均提供了相应的安全特性和最佳实践指南[^118, ^81, ^126]，企业需要充分利用并正确配置这些能力。

  企业数据上云用于AI训练或应用时，数据主权、合规性和跨区域数据流动的管理成为关键挑战。全球性的数据保护法规（如GDPR, CCPA）对个人数据的处理和跨境传输有严格要求^[40:2]。企业在使用云AI服务时，需要确保其数据存储、处理和模型训练活动符合相关法规，例如数据是否存储在特定地理区域内，是否有未经授权的跨境流动。云服务商需要提供清晰的数据处理协议、数据驻留选项、以及审计日志，帮助客户满足合规要求^[40:3]。

• 云平台特有的安全配置与管理： 各大云服务提供商（AWS, Azure, GCP等）均提供丰富的AI/ML平台和服务，但其安全性依赖于正确的配置和管理^[1:48]。错误的配置（如过于宽松的IAM策略、公开的存储桶、未加密的通信）是导致云安全事件的常见原因。用户需要清晰理解云平台的共享责任模型，并承担起“云中安全”的责任。

  云平台安全配置最佳实践示例：

  • AWS安全最佳实践： 利用IAM角色和策略进行精细化权限控制^[39:2]，使用KMS加密数据和模型^[43]，将SageMaker部署在VPC中，配置VPC端点以限制网络访问^[44]，启用CloudTrail和CloudWatch进行监控和日志记录^[39:3]。
  • Azure安全最佳实践： 使用Azure RBAC进行访问控制^[42:1]，利用Azure Key Vault管理密钥，通过Azure VNet和Private Link保护网络通信^[41:1]，使用Azure Monitor进行监控，应用Azure Policy进行合规性管理^[41:2]，并利用Azure AI Content Safety检测和过滤有害内容^[42:2]。
  • Google Cloud安全最佳实践： 依赖Google Cloud IAM进行权限管理^[45]，使用Customer-Managed Encryption Keys (CMEK)^[40:4]，配置VPC Service Controls限制数据访问^[40:5]，利用Cloud Audit Logs和Cloud Logging进行审计^[40:6]，并强调数据治理和隐私保护承诺[^125, ^126]。

  通用的缓解与防御措施包括：

  • 遵循云服务商提供的安全最佳实践和架构框架[^1, ^81]。
  • 使用云安全态势管理（CSPM）工具自动检测和修复配置错误^[1:49]。
  • 定期进行安全审计和评估，包括第三方渗透测试。
  • 利用云平台提供的安全服务，如WAF、DLP、威胁检测服务等。

2.3. AI应用与Agent开发安全风险

人工智能模型的价值最终体现在其应用中，特别是近年来兴起的AI Agent（智能体）应用。应用层面的安全风险既包括传统软件的安全问题，也包括与AI特性紧密相关的新风险，尤其是在Agent具备自主性、与外部环境交互以及依赖RAG系统获取信息时。

2.3.1. Agent开发框架与流程安全：

AI Agent通常基于特定的开发框架（如LangChain, AutoGPT, CrewAI等）构建，这些框架简化了 Agent 的开发流程，但也可能引入新的安全风险^[3:17]。开发框架本身的漏洞、库依赖风险或集成配置问题可能导致Agent被攻击或滥用^[3:18]。此外，许多Agent设计用于调用外部工具或插件（如浏览器、代码解释器、API接口）来扩展功能，不安全的插件设计（如插件输入验证不足、权限过大）可能成为攻击入口或引入新的漏洞^[3:19]。**OWASP LLM Top 10 (2025)**中将不安全的插件设计列为重要风险 (LLM07: Insecure Plugin Design)^[21:2]。

Agent的复杂交互逻辑和状态管理也可能导致意外行为或安全漏洞。例如，Agent可能在一个对话中记住敏感信息，并在后续不相关的对话中意外泄露。提示词注入（Prompt Injection）是Agent应用面临的最重要和最具挑战性的威胁之一[^11, ^130]。攻击者通过在用户输入或Agent能访问的外部数据（如网页、文档）中嵌入精心构造的恶意指令，诱导Agent执行非预期操作，如泄露敏感信息、调用危险工具、绕过安全过滤或产生有害内容[^1, ^130, ^131]。HouYi是一种针对LLM集成应用的黑盒提示注入攻击方法^[46]。此外，**过度授权（Excessive Agency - OWASP LLM08）**是指Agent被赋予了超过其任务所需的高权限或能力（如访问企业内部系统的广泛权限），一旦被攻击者控制，可能造成严重后果^[21:3]。

缓解措施包括：

• 遵循安全开发生命周期（Secure SDLC）：将安全考量融入Agent开发的各个阶段^[1:50]。
• 严格的输入验证和净化：对所有用户输入和Agent从外部获取的数据进行严格验证和净化，过滤或转义潜在的恶意指令，以防提示词注入[^1, ^130]。采用输入-输出分离或特权分离等设计模式降低提示词注入风险^[38:1]。
• 安全的插件设计和管理：对第三方插件进行严格的安全评估，限制插件的权限，在沙箱环境中运行插件，并实现插件调用过程中的安全验证和监控^[1:51]。
• 最小权限原则：严格限制Agent及其调用工具的权限（如文件系统访问、网络请求、API调用），只授予完成其特定任务所需的最低权限[^1, ^132]。
• 人工审批环节：对于高风险操作（如访问敏感系统、执行关键命令），引入人工审批环节^[1:52]。
• 持续监控Agent行为：监控Agent的API调用、工具使用、数据访问、系统交互等行为，检测异常活动和潜在滥用[^130, ^133]。
• 行为安全策略：定义Agent的行为安全策略或“护栏”（Guardrails），限制其可以执行的操作和可以生成的内容^[1:53]。

2.3.2. Agent数据交互与隐私保护：

Agent在执行任务时可能需要访问、处理和存储来自用户、企业内部系统或其他外部来源的敏感数据。如果数据交互过程缺乏安全保护，或者Agent自身存在漏洞，可能导致敏感数据被泄露、滥用或未经授权访问[^1, ^11]。Agent处理的数据量不断增加，使得数据安全与隐私保护成为其核心挑战^[1:54]。

具体风险点包括：

• 不安全的API调用：Agent调用第三方API时，如果API本身存在漏洞或认证授权机制薄弱，可能导致数据泄露或被滥用。
• 数据存储安全问题：Agent可能在本地或云端临时存储其处理的数据，如果存储位置不安全、访问控制不当或未加密，可能导致数据泄露。
• 日志记录与审计不当：Agent的交互历史和处理数据可能被记录在日志中，如果日志未脱敏或访问控制不严，可能导致敏感信息泄露。
• 隐私泄露：Agent可能无意中在对话或生成内容中泄露其从训练数据、用户输入或知识库中获取的敏感信息。

隐私保护措施：针对Agent的数据交互，需要采取以下隐私保护措施：

• 数据加密：对Agent处理、传输和存储的敏感数据进行加密，确保数据在静止和传输状态下的安全。
• 安全的API调用实践：确保Agent调用的API符合安全标准，使用安全的认证授权机制，并限制Agent可以访问的API和数据范围。
• 遵循数据最小化原则：Agent只收集和处理完成任务所需的最小量数据^[47]。
• 在Agent设计中融入隐私保护技术：探索在Agent的数据处理管道中集成差分隐私、数据脱敏或联合学习等技术^[1:55]。
• 日志脱敏与严格访问控制：对包含敏感信息的Agent日志进行脱敏处理，并对日志系统实施严格的访问控制和审计^[1:56]。
• 用户隐私控制：为用户提供对其数据如何被Agent使用和存储的控制选项^[1:57]。

2.3.3. Agent业务逻辑与场景安全：

Agent被设计用于执行特定的业务任务（如客服、营销、代码生成、自动化流程）。其业务逻辑的缺陷或对特定场景考虑不周，可能被攻击者利用，导致业务流程中断、经济损失或声誉受损。由于Agent的自主性，这些逻辑缺陷可能以不可预测的方式被触发和利用。

具体风险点包括：

• 逻辑漏洞：Agent的决策逻辑或工作流程中存在的错误，可能导致其在特定输入或状态下做出错误的、危险的或非预期的行为。
• 场景覆盖不全：Agent可能只针对预期场景进行设计和测试，对于未预见或边界场景处理不当，可能被攻击者利用。
• 滥用风险：攻击者可能通过操纵Agent的输入或环境，诱导其执行恶意操作。例如，利用客服Agent进行钓鱼攻击，诱导用户点击恶意链接或泄露个人信息。一个具备自动化能力的Agent可能被诱导执行删除文件、修改系统配置等危险操作。
• Agent联动系统及API防护需求：Agent通常需要与其他企业系统和API进行交互。必须对Agent可以访问的系统和API进行严格控制和隔离^[3:20]。Agent对外部系统的访问应通过安全的网关或代理，并实施严格的访问控制策略，限制其能力边界，防止其被滥用执行超出预期的操作^[48]。

缓解措施包括：

• 威胁建模：在Agent设计阶段，针对具体的业务场景和Agent的能力，系统性地进行威胁建模，识别潜在的攻击向量和业务风险^[1:58]。
• 全面的测试：进行全面的单元测试、集成测试和场景测试，包括对Agent逻辑的模糊测试（Fuzz Testing），向Agent发送异常或边界输入，检测业务逻辑漏洞。
• 业务规则引擎：可能引入业务规则引擎来规范Agent的行为，强制执行预设的业务逻辑和约束。
• 人工监督与干预：对于关键或高风险的Agent操作，引入人工监督或审批环节。
• 沙箱与隔离：在沙箱或受限环境中运行高风险的Agent功能，限制其潜在破坏范围^[48:1]。

2.3.4. 检索增强生成 (RAG) 系统的特定安全风险：

检索增强生成（RAG）系统是结合大型语言模型和外部知识库生成响应的常见AI应用模式，它允许模型获取最新的、领域特定的知识，提高生成内容的准确性和相关性。然而，RAG系统对外部知识库的依赖引入了独特的安全挑战^[49]。

主要风险包括：

• 检索数据泄露（Retrieval Data Leakage）：RAG系统在检索过程中需要访问知识库，如果知识库包含敏感信息（如企业内部文档、用户个人数据），且知识库的访问控制不当，或者检索结果在返回给LLM之前未经过滤，可能导致知识库中的敏感信息在检索环节被意外泄露给用户或攻击者^[49:1]。攻击者可能通过精心设计的查询来探测和提取知识库中的敏感内容。
• 嵌入向量逆向攻击（Embedding Inversion Attack）：RAG系统依赖于将知识库文档转换为嵌入向量进行相似性检索。攻击者可能尝试获取这些嵌入向量，并通过逆向工程恢复出原始敏感文本，从而窃取知识库内容^[47:1]。
• 成员推断攻击（Membership Inference Attack）：攻击者可能尝试判断特定文档或数据片段是否存在于RAG系统的知识库中^[47:2]。
• 知识库投毒/知识腐化攻击（Knowledge Corruption Attack）：这是RAG系统面临的重要威胁^[4:2]。攻击者可以向RAG系统的知识库中注入虚假、恶意或带有偏见的信息。这可以通过多种方式实现，例如在公开文档中植入错误信息（如果RAG系统从公开网络获取信息），或者直接修改可访问的内部知识库。受污染的知识库会导致Agent或LLM获取错误信息，从而影响其检索结果和最终生成的内容，导致虚假信息传播、错误决策或操纵^[4:3]。
• 间接提示词注入（Indirect Prompt Injection）：攻击者可以将恶意指令或提示词隐藏在知识库中的文档里。当RAG系统根据用户查询检索到这些被投毒的文档，并将它们作为上下文提供给LLM时，隐藏的指令可能被LLM执行，从而影响Agent的行为或输出，导致非预期的危险行为^[47:3]。这是一种通过检索到的非可信文档进行的攻击。

缓解RAG系统风险的策略包括：

• 严格的知识库访问控制和安全管理：确保知识库本身是安全的，实施细粒度访问控制，限制哪些用户或Agent可以访问哪些知识库内容^[47:4]。
• 知识库内容审查与验证：对知识库中的信息来源进行审查，验证其真实性和准确性。对于关键知识库，可以建立内容管理流程，防止未经授权的修改。构建知识链框架可以帮助追踪知识来源和修改历史^[1:59]。
• 检索结果过滤与后处理：在将检索到的文档或信息提供给LLM之前，对其进行过滤，检测和移除潜在的敏感信息、恶意内容或注入指令^[47:5]。可以对检索结果进行总结或重排序以减少敏感信息暴露^[47:6]。
• 输入/输出验证与过滤：对用户查询和RAG系统生成的响应进行安全检查，例如检测用户查询中是否包含提示词注入，检测生成内容是否包含有害信息^[47:7]。
• 数据处理与保护：对知识库中的敏感数据进行匿名化、假名化处理，或使用合成数据替代，以保护隐私^[49:2]。SAGE是一种两阶段合成数据生成范式，旨在通过属性提取和Agent迭代优化来保护隐私^[49:3]。
• 安全的检索与生成机制：例如，使用差分隐私保护检索过程^[50]，设置检索距离阈值以限制检索范围^[47:8]，只检索与查询高度相关的文档。
• 模型与知识库的隔离：考虑自托管AI模型以增强对数据流的控制^[47:9]。
• 最小化暴露原则：遵循数据最小化原则，减少知识库中存储的敏感信息量，减少不必要的知识库暴露^[47:10]。

3. 特定威胁类别与漏洞深度分析

(注：根据前文分析并遵照提供的“初稿”文档结构，原大纲中的第三章“特定威胁类别与漏洞深度分析”内容已整合并深化至第二章各风险类别（数据、算法、基础设施/API、供应链、Agent）的详细剖析中，避免重复。此处不再单独列出本章，而将相关深度分析内容保留在第二章的相应小节。)

4. DevSecOps在人工智能安全治理中的应用

面对人工智能系统贯穿全生命周期的复杂风险，传统的、孤立的安全方法难以奏效。将安全深度集成到AI系统的开发、训练、部署和运营全流程，成为必然选择。DevSecOps，即开发（Dev）、安全（Sec）、运营（Ops）的融合，以其敏捷、自动化、持续性的特点，为AI安全治理提供了有价值的参考框架。将DevSecOps原则应用于AI/ML工作流，催生了MLSecOps的概念。MLSecOps旨在弥合MLOps（机器学习运维）与DevSecOps之间的差距，将安全视为ML生命周期的核心组成部分^[3:21]。

如图2“应用于人工智能安全的MLSecOps治理模型”所示，MLSecOps将安全活动融入AI/ML的循环流程中，包括数据准备、部署、验证、监控与反馈等环节，并通过自动化安全测试、持续集成/部署、持续监控和敏捷化反馈来驱动整个过程的安全增强。

图2：应用于人工智能安全的MLSecOps治理模型

这个模型的核心思想是打破传统安全“事后审查”的模式，实现“安全左移”并贯穿整个生命周期^[1:60]。它强调在AI/ML开发的早期阶段就考虑并集成安全措施，并通过自动化和持续反馈确保安全性在整个生命周期中得到维护和提升。

4.1. DevSecOps理念在AI生命周期的应用原则

DevSecOps的核心原则与实践与AI开发运维有着天然的契合点，尤其是在强调敏捷迭代和持续交付的MLOps环境中^[1:61]。将这些原则应用于AI安全，能够构建一个更加健壮和响应迅速的安全体系。

• 安全左移（Shift Left）： 这是DevSecOps最核心的原则之一^[1:62]。将安全活动前置到AI生命周期的早期阶段。这意味着在数据准备阶段就开始考虑隐私保护和数据完整性、进行数据质量和偏见分析；在模型设计阶段就进行威胁建模、考虑模型架构的鲁棒性和可解释性；在代码开发阶段就进行安全代码编写、代码静态分析（SAST）和依赖库扫描（SCA）。早期发现并修复漏洞的成本远低于在部署甚至生产环境中修复。例如，如果在数据准备阶段发现数据偏见，可以更容易地进行数据增强或平衡；如果在模型设计阶段发现模型架构对对抗攻击敏感，可以及时调整。
• 自动化（Automation）： 大量使用自动化工具执行重复性的安全任务，是实现DevSecOps规模化和高效实施的关键^[1:63]。包括自动化的数据安全验证、代码扫描、依赖库漏洞检测、模型安全测试、基础设施配置检查、安全策略执行、以及安全事件的监控和响应。自动化减少了人工错误，加快了安全反馈循环，使安全检查能够跟上AI/ML的快速迭代速度。
• 持续集成/持续交付/持续部署 (CI/CD/CD)： 在AI开发运维流水线中嵌入自动化安全检查^[1:64]。将安全测试和验证活动集成到模型的构建、训练、测试和部署自动化流程中。例如，在每次代码提交后自动触发代码扫描和依赖库检查（CI阶段的安全）；在模型训练完成后自动触发模型安全评估和鲁棒性测试（CD阶段的安全）；在模型部署前自动进行基础设施安全配置检查和API安全测试（CD阶段的安全）。确保每次模型更新或部署都经过安全验证，防止引入新的漏洞。
• 持续监控（Continuous Monitoring）： 对AI系统行为、性能、安全事件进行实时监控和告警^[1:65]。部署后的持续监控至关重要，用于及时发现模型行为异常（可能由对抗攻击或数据漂移引起）、数据漂移、服务滥用、以及基础设施或API的安全事件。监控应涵盖技术指标（如API调用次数、错误率、资源利用率）和AI特有指标（如模型预测置信度、特定类别输出频率、生成内容的安全评分）。
• 基础设施即代码 (IaC) 与策略即代码： IaC使用代码（如Terraform, Ansible, CloudFormation模板）来定义和管理基础设施，确保环境配置的一致性、可重复性和安全性[^1, ^60, ^61]。将安全配置（如网络隔离、访问控制、加密设置）包含在IaC模板中，并进行自动化验证，防止手动配置错误。策略即代码（Policy as Code）则将安全策略、合规要求编码化（如使用Open Policy Agent - OPA），通过自动化工具在CI/CD流程和运行时环境中进行验证和强制执行，确保安全策略得到一致实施^[1:66]。
• 威胁建模（Threat Modeling）： 在设计阶段识别AI系统的潜在威胁和攻击面^[1:67]。系统性地分析AI系统可能面临的威胁、潜在漏洞和攻击路径，从而设计有针对性的防御措施。威胁建模应涵盖数据来源和处理、模型架构和训练、部署环境、API接口、以及用户交互等各个方面。可以利用MITRE ATLAS等框架来指导AI系统的威胁建模[^1, ^5]。
• 安全文化与协作： 培养跨团队的安全意识和责任共担文化^[1:68]。打破开发、数据科学家、ML工程师、安全和运营团队之间的壁垒，促进紧密协作。安全不再是安全团队的专属任务，而是所有参与AI系统开发和运营人员的共同职责。通过定期的安全培训、跨团队交流和联合演练，提升整体安全能力。

4.2. DevSecOps如何应对已识别的AI风险

将DevSecOps原则应用于AI生命周期，可以构建具体的实践来应对前面章节识别的各类风险：

• 应对数据风险：

  • 自动化数据验证和清洗： 在数据准备和摄取管道中集成自动化工具，执行数据格式、质量、完整性验证，检测异常值、重复值、甚至潜在投毒或异常模式^[1:69]。例如，使用数据概要分析工具、数据质量检查库，或基于异常检测模型来标记可疑数据。
  • 差分隐私/脱敏集成： 将差分隐私库（如Google的DP library, Opacus for PyTorch）或数据脱敏工具自动化地集成到数据处理管道中，确保敏感数据在被用于训练前得到处理^[1:70]。策略即代码可用于强制执行数据脱敏策略。
  • 数据血缘追溯： 构建自动化流程记录数据的来源、采集方式、处理步骤和版本信息（数据血缘），支持数据溯源，有助于在发现投毒或偏见时快速定位问题来源^[1:71]。
  • 供应链数据源审查自动化： 将第三方数据源的安全评估和审查纳入DevSecOps流程，例如通过自动化工具检查数据提供商的认证、安全报告，或对数据样本进行自动化扫描。
  • 自动化偏见检测与缓解： 在数据分析和准备阶段集成自动化偏见检测工具（如AI Fairness 360^[51]），并尝试自动化应用偏见缓解技术（如数据重采样）。

• 应对算法风险：

  • 自动化模型鲁棒性测试： 在CI/CD流程中集成自动化工具，对模型进行对抗样本鲁棒性测试^[1:72]。使用如Foolbox, ART^[52], CleverHans^[51:1]等库，自动生成对抗样本并评估模型在这些样本上的表现。
  • 对抗训练集成： 将对抗训练步骤自动化地集成到模型训练流程中^[1:73]。自动化脚本可以在训练过程中定期生成对抗样本并用于模型更新。
  • 模型漏洞扫描： 使用自动化工具（如Protect AI ModelScan^[52:1], Garak^[52:2]）扫描模型文件或模型架构是否存在已知漏洞或后门特征^[1:74]。
  • 自动化后门检测与移除： 集成自动化工具来检测模型中是否存在后门。虽然这仍然是一个研究挑战，但某些基于模型行为或内部激活模式的检测方法可以尝试自动化。
  • 模型行为监控与异常检测： 持续监控部署模型的行为，检测异常预测、对特定输入的敏感性、输出模式的改变等，可能指示对抗攻击或后门触发^[1:75]。利用另一个AI模型或统计方法来监测目标模型的输出分布或预测置信度。

• 应对部署风险：

  • 自动化基础设施配置安全检查： 使用IaC工具（如Terraform, CloudFormation, Ansible）和IaC安全策略检查工具（如Checkov, Terrascan）自动化验证部署环境的安全配置[^1, ^60, ^61]。在将IaC代码部署到云端之前，在CI流程中自动进行安全扫描。
  • 容器安全扫描： 对用于部署模型的容器镜像（如Docker镜像）进行自动化安全扫描，检测操作系统漏洞、软件包漏洞、恶意代码或配置错误^[1:76]。可以使用如Trivy, Clair等工具。
  • API安全自动化测试： 将API安全测试工具（如OWASP ZAP, Burp Suite）集成到部署流水线，自动化测试API的认证、授权、输入验证、速率限制等方面^[1:77]。特别针对AI模型API，需要进行专门的模糊测试和模式检测。
  • 运行时应用自保护（RASP）： 在模型推理服务运行时集成RASP工具，监测和阻止恶意输入或行为，例如防止通过Prompt注入攻击执行危险系统命令^[1:78]。
  • 自动化模型签名与验证： 在模型训练或构建完成后，自动生成模型文件的数字签名。在模型部署时，自动化验证签名，确保模型未被篡改^[1:79]。

• 应对供应链风险：

  • 自动化组件漏洞扫描（SCA）： 集成SCA工具（如OWASP Dependency-Check, Sonatype Nexus Lifecycle, Snyk）到代码构建流程，自动扫描所有依赖库和组件的已知漏洞^[1:80]。
  • AI-BOM自动化生成与管理： 探索自动化工具生成和更新AI-BOM，记录AI系统的所有组件（数据集、模型、库、工具）及其来源、版本和许可证信息[^1, ^30, ^34]。将AI-BOM集成到资产管理系统，并自动化监控AI-BOM中组件的漏洞和许可证合规性[^186]。
  • 对第三方模型和配置文件进行自动化安全扫描： 在CI/CD流程中增加步骤，自动化扫描从外部（如模型仓库）获取的模型文件和配置文件，检测恶意内容[^29, ^31]。

• 应对Agent风险：

  • Agent代码安全扫描与模糊测试： 对Agent核心逻辑和插件代码进行自动化SAST和模糊测试，检测代码漏洞和逻辑缺陷^[3:22]。
  • 知识库完整性自动化验证： 对于RAG系统的知识库，建立自动化流程定期检查内容的完整性，检测异常修改或注入的恶意内容^[1:81]。可以结合数字签名或区块链技术。
  • Prompt注入自动化检测与缓解： 在Agent的输入处理模块集成自动化工具，检测和过滤潜在的Prompt注入攻击[^1, ^130]。在Agent的输出模块进行自动化审核。
  • Agent行为监控与策略执行： 部署Agent运行时监控工具，记录Agent的工具调用、API访问、数据交互等行为，并根据预定义的策略（策略即代码）自动化阻止高风险操作^[1:82]。
  • 自动化权限配置与审计： 使用IaC和策略即代码自动化配置和审计Agent的运行环境和对外部资源的访问权限^[48:2]。

4.3. DevSecOps在AI中的实践落地

将DevSecOps理念落地到AI安全实践中，需要构建相应的组织架构、工具链和流程，并将这些实践融入现有的AI/ML开发和运营工作流。

• AI安全CI/CD流水线构建： 核心是将各种安全活动融入CI/CD流程，形成一个包含安全门禁的自动化流水线。如图2所示，这个流水线是持续循环的，反馈环路确保了安全问题的快速发现和解决^[1:83]。

  • 数据准备与代码开发阶段（安全左移）：
    • 自动化数据质量与隐私检查：数据摄取后自动触发数据概要分析、敏感信息识别、偏见检测、差分隐私/脱敏处理（如果需要）^[1:84]。
    • 代码静态分析（SAST）：开发者提交代码后自动扫描代码中的安全漏洞^[1:85]。
    • 软件成分分析（SCA）：自动扫描项目依赖库，检查已知漏洞和许可证合规性^[1:86]。
    • IaC安全扫描：如果使用IaC定义训练或部署环境，自动扫描IaC代码的安全配置问题。
    • 威胁建模：虽然不是自动化步骤，但应在AI系统设计早期（对应CI/CD流程的初始设计阶段）系统进行威胁建模^[1:87]。
  • 模型训练与验证阶段：
    • 自动化鲁棒性测试：模型训练完成后，自动生成对抗样本并测试模型的鲁棒性^[1:88]。
    • 模型安全扫描：自动扫描模型文件，检测潜在的后门、恶意权重或格式问题^[1:89]。
    • 偏见与公平性评估：自动运行偏见评估指标，检查模型是否存在不公平输出^[1:90]。
  • 模型部署阶段：
    • 容器镜像安全扫描：如果使用容器部署，自动扫描容器镜像的漏洞和配置问题^[1:91]。
    • 基础设施安全配置检查：使用策略即代码工具检查部署环境的基础设施配置是否符合安全基线^[1:92]。
    • API安全自动化测试：部署前自动运行API安全测试用例，检查认证、授权、输入验证等^[1:93]。
    • 模型签名与验证：自动化对部署的模型文件进行签名，并在加载模型时进行验证^[1:94]。
  • 发布与运营阶段：
    • 持续监控：部署后，持续收集日志和监控数据，监测系统行为、模型性能、API调用模式、Agent行为等^[1:95]。
    • 运行时保护：部署RASP或AI护栏（Guardrails）等工具提供运行时保护^[1:96].
    • 自动化响应：基于监控告警，触发自动化的安全响应流程^[1:97]。
    • 定期红队测试：自动化或半自动化地进行周期性AI红队测试[^1, ^5]。

• AI特有的安全工具链整合： 实现上述流程需要一套涵盖传统安全和AI特有安全能力的工具链[^1, ^2]。这要求将各种独立的工具集成到统一的DevSecOps平台或流水线中^[53]。

  • 传统安全工具的扩展应用： SAST/DAST/SCA工具^[1:98]、IaC安全工具^[1:99]、容器安全工具、SIEM/SOAR平台^[1:100]都需要能够处理AI项目中的代码、配置和日志。
  • AI特有的安全工具与技术：
    • 数据安全工具： 数据脱敏和匿名化工具、差分隐私库（如Opacus）、自动化偏见检测与缓解工具（如AI Fairness 360^[51:2]）^[1:101]。
    • 模型安全工具： 对抗攻攻击生成与防御库（如IBM ART^[52:3]、CleverHans^[51:3]、Foolbox^[51:4]）、模型可解释性工具（如LIME, SHAP^[1:102]）、模型漏洞扫描器（如Protect AI ModelScan^[52:4]、Garak^[52:5]）、后门检测工具^[1:103]。
    • 应用安全工具： AI API安全网关、WAF、RASP、Agent运行时监控工具^[1:104]。
    • 治理与测试工具：
      • AI红队测试与评估框架： SafeBench是一系列用于评估AI安全性和风险的基准测试套件，包括Cybench（网络安全能力）、AgentDojo（Prompt注入）、BackdoorLLM（后门攻击）、U-SafeBench（用户特定安全评估）、MM-SafetyBench（多模态安全）等^[54]。MITRE ATLAS提供了AI攻击技术知识库，指导威胁建模[^1, ^5]。OWASP GenAI Security Project提供针对生成式AI的安全指南和测试方法^[55]。Microsoft PyRIT是用于生成式AI模型风险识别的开源工具^[52:6]。这些框架和工具为自动化红队测试提供了方法和实现。
      • AI安全评估平台： AIcert平台提供从理论验证到安全开发的综合评估能力^[55:1]。
      • AI驱动的安全工具： 利用AI自身的能力提升安全工具的效率和智能性，例如AI驱动的代码安全分析平台（如VackSCA^[55:2]），AI驱动的异常检测和威胁情报分析。

• 持续监控与响应： 这是DevSecOps在运营阶段的核心实践，在AI场景下需要额外关注AI特有的监控指标^[1:105]。

  • AI系统行为异常检测： 监控模型预测输出的统计特征（如预测概率分布、特定类别输出频率）、模型性能指标（如准确率、延迟）、资源利用率（CPU/GPU、内存）^[1:106]。检测与基线行为的偏差，可能指示对抗攻击、数据漂移或服务滥用。
  • 模型输出监控与内容审核： 特别对于生成式AI，持续监控模型的输出内容，检测是否包含有害、偏见、不实信息或泄露敏感信息。利用AI护栏（Guardrails）或内容审核服务进行自动化过滤^[1:107]。
  • Agent行为监控与控制： 监控Agent的API调用、工具使用、系统交互、数据访问等行为，检测是否执行了高风险或非预期的操作^[1:108]。
  • 安全事件告警与关联分析： 将AI系统和基础设施的监控数据、安全日志（如WAF日志、API网关日志、审计日志）与安全信息和事件管理（SIEM）系统集成，自动化关联分析，生成安全告警^[1:109]。
  • 自动化响应机制： 针对识别的安全事件，触发自动化的响应流程，如隔离受感染组件、回滚到安全模型版本、自动触发额外验证、阻止异常IP访问等^[1:110]。

• 基于策略的代码： 将AI安全策略（例如，禁止高风险Agent调用特定API、所有训练数据必须经过脱敏处理、模型部署必须经过漏洞扫描等）编码化，通过策略即代码工具（如OPA）在CI/CD流水线、Kubernetes准入控制器、云基础设施配置验证等环节进行自动化强制执行^[1:111]。这确保了安全策略能够一致、大规模地落地。

4.4. MLSecOps与DevSecOps及其它框架的比较与融合

• MLOps与DevOps： DevOps专注于传统软件的开发、部署和运维自动化，强调文化、自动化、精益和测量^[1:112]。它解决的是传统软件交付效率和稳定性的问题。MLOps（Machine Learning Operations）则在此基础上，专注于机器学习模型的全生命周期管理^[3:23]。MLOps关注ML特有的环节，如数据准备（数据版本控制、血缘追踪）、模型训练（实验追踪、超参数调优）、模型注册与版本控制、模型部署（A/B测试、金丝雀发布）、模型监控（性能漂移、数据漂移）和再训练[^1, ^56]。MLOps的核心目标是使ML模型的开发和部署像传统软件一样高效和可靠。

• MLSecOps： MLSecOps是MLOps与DevSecOps的深度融合[^1, ^2]。它不仅仅是在MLOps流程中加入传统的安全检查点，而是将DevSecOps的安全左移、持续自动化和协作文化融入ML全生命周期的每一个环节。MLSecOps更聚焦于AI/ML特有的安全挑战，如数据管道安全、模型训练的鲁棒性与隐私、模型部署的API与运行时安全、以及模型治理与合规性^[1:113]。它是在MLOps流程中内建安全能力，确保交付的AI系统既高效又安全可信。MLSecOps的关键实践包括：安全的模型开发训练（如数据验证、差分隐私、鲁棒性测试集成到训练流程）、安全的模型部署集成（如模型签名验证、API安全加固、容器安全扫描集成到部署流程）、持续的模型监控防护（如模型行为监控、输出内容过滤、威胁检测）和模型治理合规（如AI-BOM管理、法规遵守自动化）^[1:114]。JFrog ML等平台正在尝试将MLOps与DevSecOps结合，提供统一的AI交付平台^[53:1]。

• 与其他AI安全框架的互补（NIST AI RMF, MITRE ATLAS, OWASP GenAI Security Project）： DevSecOps/MLSecOps提供的是实践路径和操作框架^[1:115]。它们关注的是如何在AI/ML生命周期中落地安全活动。而其他AI安全框架提供了风险分类、治理原则、评估标准和威胁知识[^1, ^5]。

  • NIST AI Risk Management Framework (AI RMF) 提供了一个结构化的AI风险管理流程（识别、分析、应对、治理），是一个自愿性的、高层框架[^1, ^5, ^113]。它帮助组织建立AI风险管理的策略和流程，但没有提供具体的技术实现细节。
  • MITRE ATLAS 提供了一个AI攻击技术分类和知识库，以矩阵形式列出了AI系统可能面临的攻击技术（14个攻击阶段，66个策略）[^1, ^5, ^134]。它帮助安全团队理解AI威胁全景，指导威胁建模和防御体系建设。
  • OWASP GenAI Security Project 提供针对生成式AI和LLM的具体安全指南、漏洞列表（从LLM Top 10升级）和安全测试方法，更加聚焦应用层面的风险^[55:3]。它提供了具体的攻击手法示例和防御建议。

  **MLSecOps可以将这些框架提供的风险知识、评估标准和最佳实践转化为具体的自动化流程和工具链，落地到AI系统的开发运维中。**例如，可以利用MITRE ATLAS指导在Agent设计阶段进行威胁建模；利用OWASP GenAI Security Project的测试方法（如Prompt注入测试用例）自动化评估LLM应用的安全性，并将其集成到CI/CD流程中；可以将符合NIST AI RMF的风险管理活动（如风险识别、评估、监控）集成到持续的MLSecOps流程中。它们是互补而非竞争关系，MLSecOps为这些框架的落地提供了可操作的实践路径，共同构成了全面的AI安全治理体系。

<svg width="700" height="400" xmlns="http://www.w3.org/2000/svg">
  <style>
    .box { fill: #4682B4; stroke: #000; stroke-width: 1; }
    .text { font-family: Arial, sans-serif; font-size: 14px; fill: #fff; text-anchor: middle; dominant-baseline: middle; }
    .large-text { font-family: Arial, sans-serif; font-size: 16px; fill: #fff; text-anchor: middle; dominant-baseline: middle; font-weight: bold; }
    .arrow { stroke: #000; stroke-width: 1.5; marker-end: url(#arrowhead); }
    #arrowhead { markerUnits: strokeWidth; refX: 0; refY: 2; orient: auto; markerWidth: 10; markerHeight: 10; fill: #000; stroke: #000;}
    .frame { fill: none; stroke: #000; stroke-width: 1; stroke-dasharray: 5,5; }
    .label { font-family: Arial, sans-serif; font-size: 12px; fill: #000; }
  </style>
  <marker id="arrowhead" viewBox="0 0 10 4" refX="0" refY="2" markerUnits="strokeWidth" orient="auto" markerWidth="5" markerHeight="3">
    <path d="M 0 0 L 10 2 L 0 4 z" fill="#000"/>
  </marker>

  <!-- ML Life Cycle -->
  <circle class="box" cx="350" cy="180" r="80"/>
  <text class="large-text" x="350" y="180">MLOps</text>
  
  <rect class="box" x="300" y="70" width="100" height="30" rx="5" ry="5"/>
  <text class="text" x="350" y="85">数据准备</text>

  <rect class="box" x="450" y="170" width="100" height="30" rx="5" ry="5"/>
  <text class="text" x="500" y="185">训练</text>

  <rect class="box" x="300" y="270" width="100" height="30" rx="5" ry="5"/>
  <text class="text" x="350" y="285">部署</text>

  <rect class="box" x="150" y="170" width="100" height="30" rx="5" ry="5"/>
  <text class="text" x="200" y="185">验证</text>

  <line class="arrow" x1="350" y1="100" x2="470" y2="170"/>
  <line class="arrow" x1="550" y1="185" x2="400" y2="285"/>
  <line class="arrow" x1="350" y1="300" x2="230" y2="195"/>
  <line class="arrow" x1="150" y1="185" x2="300" y2="85"/>

  <!-- DevSecOps Principles -->
  <rect class="box" x="50" y="330" width="120" height="30" rx="5" ry="5"/>
  <text class="text" x="110" y="345">安全左移</text>

  <rect class="box" x="200" y="330" width="120" height="30" rx="5" ry="5"/>
  <text class="text" x="260" y="345">自动化</text>

  <rect class="box" x="350" y="330" width="120" height="30" rx="5" ry="5"/>
  <text class="text" x="410" y="345">持续监控</text>

  <rect class="box" x="500" y="330" width="120" height="30" rx="5" ry="5"/>
  <text class="text" x="560" y="345">威胁建模/协作</text>

  <!-- MLSecOps Frame -->
  <rect class="frame" x="100" y="40" width="500" height="330" rx="10" ry="10"/>
  <text class="label" x="110" y="55">MLSecOps (融合DevSecOps原则)</text>
  
</svg>

图4.1: MLOps与DevSecOps的融合示意图

这幅示意图展示了MLOps涵盖的机器学习生命周期核心环节（数据准备、训练、验证、部署）以及DevSecOps的核心原则（安全左移、自动化、持续监控、威胁建模/协作）。MLSecOps（用虚线框表示）正是将DevSecOps的这些原则和实践深度融入到MLOps的各个环节中，确保在机器学习全生命周期中内建安全。

5. 监管、伦理与地缘政治更广阔背景

人工智能的飞速发展不仅带来了技术和应用层面的挑战，也引发了广泛的社会、伦理、法律和地缘政治层面的关切[^1, ^2, ^4, ^5]。AI安全治理必须置于这个更广阔的背景下考量，理解其与全球规则制定、社会价值观以及国家战略之间的复杂相互作用。

5.1. 监管合规：全球与中国的AI法规现状与趋势

全球主要经济体都在积极制定和完善AI监管框架，以平衡创新发展与潜在风险。虽然路径不同，但都朝着加强风险管理、提升透明度和确保安全可控的方向发展[^1, ^2, ^6]。

• 全球主要监管框架：
  • 欧盟《人工智能法案》（EU AI Act）： 被认为是全球首部全面规范AI的法律框架，已于2024年8月1日正式生效[^1, ^6]。法案采取基于风险的分级管理方法[^1, ^2, ^6]：
    • 不可接受风险： 被认为对基本权利和民主构成明显威胁的AI系统被禁用（例如，利用潜意识操纵技术、利用弱势群体漏洞、社会评分系统、实时远程生物识别身份识别系统等，执法需要严格例外）。
    • 高风险： 对人类健康、安全、基本权利或环境构成重大风险的AI系统，例如用于关键基础设施管理、医疗诊断、教育和招聘决策、执法和司法判决、移民和边境控制等领域的系统[^1, ^2, ^6]。高风险AI系统面临最严格的强制性合规要求，包括建立和实施风险管理系统、确保数据集质量和治理、记录活动以便实现可追溯性、提供清晰的用户信息、确保人类监督、达到高水平的准确性、鲁棒性和网络安全等[^1, ^2, ^6]。提供者需要在欧盟数据库中注册高风险系统，并进行合规性评估。
    • 有限风险： 需要遵守特定的透明度义务，例如明确告知用户正在与AI系统交互（如聊天机器人）、对生成式AI内容进行标识[^1, ^6]。
    • 最低风险： 绝大多数AI系统属于此类，法案不施加额外义务，但鼓励遵守自愿性行为准则[^1, ^6]。
  • 通用目的AI (GPAI) 模型： 法案对基础模型（Foundation Models）提出了特定要求，特别是具有系统性风险的大模型（根据模型计算能力和下游影响判断），需要遵守更严格的义务，例如进行模型评估、评估和减轻系统性风险、提供技术文档、尊重版权（披露训练数据摘要）等[^140, ^141]。该法案预计将对全球AI治理产生深远影响，形成“布鲁塞尔效应”[^142, ^143, ^144]。
  • 美国AI监管： 美国采取更为多中心化、市场驱动的监管方式^[3:24]。联邦层面缺乏统一的综合性AI法案，主要依赖行政部门的行动（如总统行政令）和现有行业法规（如医疗、金融领域的法规）来管理AI[^1, ^5]。核心理念是鼓励创新，通过自愿性框架和行业自律来引导AI的负责任发展。
    • NIST AI风险管理框架 (NIST AI RMF)：由美国国家标准与技术研究院发布，是一个自愿性框架，旨在帮助组织更好地管理与AI系统相关的风险，提升AI系统的可信赖性[^1, ^5, ^113]。框架包括“治理”（制定风险策略）、“识别”（发现风险）、“测量”（评估风险）和“管理”（应对风险）四大核心功能，强调在AI生命周期的各个阶段融入可信赖性考量（如有效性、可靠性、安全性、偏见缓解和透明度）。NIST还发布了针对生成式AI的特定配置文件，指导如何应用AI RMF管理GenAI风险[^113, ^201]。
    • 总统行政令：美国总统发布了关于人工智能的行政命令，要求各联邦机构制定AI安全标准、促进AI研发、保护隐私、推动公平性等，旨在利用政府购买力推动行业最佳实践[^1, ^5]。
    • “红队+第三方评估”：强调通过模拟攻击（红队）和独立的第三方评估来验证AI系统的安全性、鲁棒性和公平性[^1, ^5]。
    • 州层面立法：由于联邦立法进展缓慢，一些州先行立法，例如加州。
  • OECD AI原则： 经济合作与发展组织提出了一系列以人文本的AI原则，强调包容性增长、可持续发展、人类价值观、法治、透明度和可解释性、鲁棒性、安全性以及问责制^[1:116]。这些原则为各国制定AI政策提供了指导，是国际社会在AI治理方面达成的早期共识之一。
  • IEEE 伦理对齐设计 (EAD)： 电气和电子工程师协会提供了一系列标准和指南，旨在帮助设计者和开发者在AI和自主系统中嵌入伦理考量^[1:117]。

这些国际框架和原则共同构成了全球AI治理的初步格局，其核心思想在于通过风险评估、透明度要求、问责机制和伦理考量来引导AI的负责任发展。然而，不同国家和地区在具体立法和监管实践中可能存在差异，给跨国运营的企业带来合规挑战。

• 中国AI监管政策与标准： 中国政府高度重视人工智能的发展及其带来的风险，并已出台一系列政策法规和标准以规范AI的应用[^1, ^2, ^6]。核心理念是发展与安全并重，在鼓励技术创新的同时，注重防范潜在风险，保护国家安全、社会公共利益和公民合法权益。监管思路采取**分类分级管理，“包容审慎”**的方式，根据AI的风险等级和应用领域进行差异化管理^[3:25]。

  • 顶层设计与治理原则： 发布《新一代人工智能治理原则——发展负责任的人工智能》，提出了和谐友好、公平公正、包容共享、尊重隐私、安全可控、共担责任、开放协作、敏捷治理八项原则[^1, ^155]。
  • 生成式AI专项法规：
    • 《互联网信息服务深度合成管理规定》： 针对利用深度合成技术（包括生成式AI）提供服务的活动，要求明确标识合成内容、防范虚假信息、加强技术管理等[^1, ^2]。
    • 《生成式人工智能服务管理暂行办法》： 对生成式AI服务提供者提出明确要求，包括内容合规性、采取有效措施防止产生歧视性内容、尊重他人合法权益、进行安全评估和算法备案等[^1, ^2]。
  • 算法推荐管理： 《互联网信息服务算法推荐管理规定》旨在规范算法推荐活动，要求提供者保障用户权益，如算法解释权、选择或关闭算法推荐服务的权利，并禁止利用算法进行不正当竞争或侵害用户权益^[1:118]。
  • 数据安全与个人信息保护： 《数据安全法》和《个人信息保护法》等法律法规对AI应用中的数据处理活动（包括个人信息）提出了严格的合规要求，为AI发展划定了数据使用的红线。
  • 标准化工作： 全国信息安全标准化技术委员会（TC260）等机构正在积极制定AI安全相关的国家标准，例如《网络安全技术 人工智能计算平台安全框架》^[56]和《网络安全技术 生成式人工智能预训练和优化训练数据安全规范》^[57]，这些标准为AI系统的安全设计和数据处理提供了具体指引。后者详细规定了预训练和优化训练数据的通用安全要求（如分类分级、安全防护、安全监测、审计追溯、应急响应）和数据处理活动安全要求（如数据收集、预处理、使用）^[57:1]。
  • 评估与备案制度： 工信部、网信办等部门正在推进AI算法和模型的安全评估和备案制度，对AI系统进行动态审查和管理。
  • 社会信用体系的潜在应用： 中国正在探索将社会信用体系应用于AI治理，通过建立覆盖人工智能研发应用全生命周期的信用评价机制，评估研发企业、应用主体、数据提供者等的信用状况，引导资源流向信用良好主体，激励企业加强安全和隐私保护投入^[3:26]。同时，将诚信价值观融入人工智能研发应用，形成具有广泛约束力的行业伦理准则，从源头防范技术滥用风险^[3:27]。应用信用手段加强数据来源合法性、使用合规性和质量可靠性的监管，解决数据孤岛、滥用、安全等问题^[3:28]。

  中国的AI监管体系正在逐步完善，强调发展与安全并重，鼓励技术创新的同时，也注重防范潜在风险，保护国家安全、社会公共利益和公民合法权益。

• AIGC标识义务对比： 为了应对深度伪造（Deepfake）和虚假信息传播带来的“真相侵蚀”^[3:29]，全球主要经济体都在推动对AI生成内容（AIGC）的标识要求，以提高透明度和可信度，但具体方式有所差异[^2, ^6]。

  • 欧盟： EU AI Act强制要求生成式AI系统提供商确保AIGC能够被可机读标识（如水印、元数据）并可检测为人工生成或操纵[^2, ^6]。欧盟AI公约（EU AI Pact）也鼓励清晰可区分的AIGC标识。法案提倡技术方案的互操作性，可能通过遵循C2PA（内容来源与真实性联盟）等标准实现，以便跨平台和工具识别AIGC[^2, ^6]。
  • 美国（加州CAITA）： 联邦层面缺乏统一的立法，主要依赖行政指导和行业自律^[3:30]。加州AI透明度法案（CAITA）则走在前列，针对大型AIGC服务提供商（每月用户超过100万）设置了标识义务^[3:31]。CAITA要求提供商强制提供隐式（latent）标识（如元数据或难以察觉的水印），并允许用户可选添加显式（manifest）标识（如可见的水印或文字声明）^[3:32]。该法案于2026年1月1日生效，重点在于透明度，而非对内容本身的限制^[3:33]。
  • 中国： 采取多层法规体系，对AIGC标识提出要求^[3:34]。包括《互联网信息服务深度合成管理规定》、《生成式人工智能服务管理暂行办法》以及《人工智能生成合成内容标识办法（征求意见稿）》等[^2, ^6]。要求服务提供者对使用深度合成技术生成或编辑的信息内容进行显著标识^[3:35]。对于可能轻易导致公众混淆的内容，允许用户选择性地添加显式标识^[3:36]。同时，要求嵌入元数据隐式标识，以便机器识别。《标识办法》正在推动标准化隐式标识格式，以方便普遍识别^[3:37]。 中美欧在监管范围（全面法案 vs 专项法规）、强制性程度和标识方式（隐式/显式、强制/可选）上存在差异，反映了各自在平衡创新、安全和价值观上的不同侧重[^2, ^6]。这些差异给跨国AI服务提供了合规挑战。

• 审计与合规实践： 将法规要求融入DevSecOps流水线是实现合规性的关键实践^[1:119]。通过自动化合规检查工具，可以在AI系统的开发、部署和运营过程中持续验证是否满足GDPR、HIPAA、PCI DSS等数据隐私和安全法规要求，以及AI特有法规的要求^[1:120]。例如，自动化检查数据处理是否符合隐私政策、模型部署是否符合高风险系统要求、AIGC是否包含标识元数据等。同时，独立的第三方合规评估也日益重要，确保AI系统符合特定行业标准或国家法规^[55:4]。**国际标准化组织（如ISO/IEC 42001）**也发布了关于AI管理体系的标准，为企业建立合规框架提供指导[^1, ^5, ^11]。

5.2. 伦理考量与社会影响

人工智能的广泛应用带来了深刻的伦理挑战和社会影响，这些问题与AI安全风险密切相关，需要从更宽泛的维度加以治理[^1, ^2, ^4, ^5, ^12]。忽视伦理和社会影响，不仅可能导致AI技术偏离服务人类福祉的初衷，也可能引发法律、监管和社会抵制等问题，最终影响AI的可持续发展。

• 算法偏见与歧视： 如2.1.1节所述，源于训练数据的算法偏见^[1:121]可能在AI模型的决策中放大，导致在招聘、信贷审批、司法判决^[22:1]、医疗诊断^[15:8]等领域出现歧视性结果，对特定群体造成不公^[1:122]。社交媒体算法可能通过奖励极端言论加剧网络对立和社会分裂^[1:123]。金融领域的AI应用也面临复杂的伦理考量，需要灵活和预防性的治理，建立全面的AI伦理框架^[58]。治理需要技术（偏见检测与缓解）与非技术手段（流程审查、伦理指导）结合。
• 隐私侵犯与监控风险： AI驱动的监控技术（如面部识别、行为分析）的滥用可能导致大规模隐私侵犯，甚至形成“全面监控”，威胁个人自由和公民权利[^1, ^5]。智能音箱、摄像头等边缘AI设备可能在未经用户明确授权的情况下收集和传输敏感数据。大型模型对用户输入的处理和存储也存在隐私泄露风险^[1:124]。生物识别技术的广泛应用带来了新的隐私和安全挑战。
• 目标错位与对齐问题（AI Alignment Problem）： 特别是对于具有一定自主性的AI Agent或高级AI系统，其设计目标可能与人类的真实意图、价值观或预期不完全一致，导致“目标错位”或“对齐问题”^[1:125]。例如，一个被设定为“最大化用户点击量”的新闻推荐算法，可能为了达成目标而推荐虚假或耸人听闻的内容，即使这不是开发者或用户期望的。一个具有物理操作能力的Agent，为了完成任务可能采取对环境或人类有害的行动。确保AI行为与人类价值观对齐是AI安全和伦理的核心挑战之一，特别是随着AI能力的增强，确保其行为可预测、可控且符合人类利益变得越来越重要[^152]。
• 虚假信息与操纵： 生成式AI技术，尤其是深伪（Deepfake）技术和大规模内容生成能力，使得虚假信息的制作和传播变得更加容易、逼真且难以追溯[^1, ^5, ^46]。这可能被用于舆论操纵、政治干预、欺诈、网络欺凌、敲诈勒索等。例如，利用深伪技术生成虚假视频或音频，冒充他人进行欺诈或诽谤。AI生成的虚假新闻或社交媒体内容可能被用于影响公众舆论或煽动社会矛盾^[1:126]。这破坏了信息生态和社会的信任基础。
• 就业与经济结构影响： AI自动化能力可能取代部分人类工作岗位，对劳动力市场和经济结构产生深远影响[^1, ^5, ^154]。虽然这并非直接安全风险，但它引发了关于失业、收入差距、技能再培训、社会福利等问题，可能导致社会不稳定。
• 责任归属困境： 当AI系统做出错误决策、造成损失或被滥用时，法律责任的界定复杂且模糊^[1:127]。例如，自动驾驶汽车发生事故、AI医疗诊断失误、或Agent执行错误操作导致损失，责任应归属于谁？是数据提供者、模型开发者、部署者、使用者，还是AI系统本身？现有的法律框架难以直接套用，这带来了责任归属的困境，需要法律和伦理框架的完善。
• 伦理框架与治理实践： 为了应对这些挑战，需要将抽象的伦理原则转化为具体的治理实践。企业和研究机构设立伦理委员会^[1:128]，制定AI使用准则，将伦理原则嵌入技术开发流程，例如在AI设计和评估阶段纳入伦理考量，进行偏见审查和社会影响评估^[1:129]。探索社会信用体系在AI治理中的作用^[3:38]，通过建立信用评价机制引导负责任的AI发展，将算法透明度、数据合规性纳入诚信考量，并推动行业伦理准则的形成^[3:39]。中国政府和科技公司也积极推动AI伦理治理，例如发布伦理原则和框架[^155, ^160]，强调安全、透明、可问责和公平等原则[^156, ^157, ^158, ^159, ^161, ^162]。

5.3. 地缘政治风险

人工智能作为一种具有广泛应用前景和巨大潜力的技术，已成为战略性通用技术，其发展、控制和应用对国家实力、国际格局和全球治理产生深远影响，带来了显著的地缘政治风险[^1, ^3, ^5, ^163, ^164, ^165]。国家间的AI竞争和潜在的恶意使用，可能加剧国际紧张局势。

• AI军备竞赛与军事应用： AI的军民两用性使其成为各国竞相投入的战略高地^[59]。各国都在积极探索和发展AI在军事领域的应用，包括自主武器系统、情报分析、网络攻防、指挥控制、后勤保障等^[1:130]。这可能引发新的军备竞赛，改变战争形态（如加速决策速度、降低人类干预、扩大作战范围），并带来严重的伦理和国际法挑战（如自主武器的伦理问题、误判风险）^[1:131]。
• 技术主权与战略依赖： AI的核心技术（如高端芯片、基础软件、大型模型）的掌握程度成为衡量国家科技实力和战略自主性的重要指标^[1:132]。对外部AI技术和平台的过度依赖可能威胁国家技术主权、经济安全和产业链安全，使国家在关键领域受制于人。因此，各国都强调自立自强，集中力量攻克关键核心技术，构建自主可控的基础软硬件系统^[1:133]。
• 关键基础设施风险： AI技术越来越多地应用于能源、交通、通信、金融、核设施等关键基础设施领域的管理和运营^[1:134]。这些AI系统一旦遭受攻击或失控，可能对国家安全和经济稳定造成严重冲击，例如导致电网瘫痪、交通系统停摆、金融市场混乱等。
• 认知战与信息安全： AI生成虚假信息、分析社交媒体、定向投放宣传等能力，为认知战和影响力行动提供了新的工具^[1:135]。利用AI进行大规模的信息制造和传播，煽动社会矛盾，干预他国内政，进行认知域对抗，对国家信息安全、社会稳定和民主进程构成严峻挑战^[1:136]。
• 经济竞争与产业格局重塑： AI驱动的产业变革正在重塑全球经济格局。各国政府纷纷出台AI发展战略，争夺AI技术和产业的制高点，这加剧了国际经济竞争和潜在的贸易摩擦。AI在提升生产效率和改变商业模式方面的潜力，也可能影响国家间的经济力量平衡。

地缘政治因素也反过来影响AI的全球治理。国家间的战略竞争可能阻碍在AI安全标准、数据共享、伦理规范等方面达成全球共识，形成“AI治理赤字”。缺乏统一的国际规范，可能导致“竞底效应”，即一些国家为了追求技术优势而放松安全和伦理约束，增加全球AI风险。因此，在推动AI技术发展的同时，必须高度关注其地缘政治和国家安全意涵，加强战略研判和风险管控，并通过国际对话与合作寻求共同安全之道，促进各国在发展战略、治理规则、技术标准等方面的对接协调，早日形成具有广泛共识的全球治理框架和标准规范[^1, ^5]。相关研究机构如CNAS^[60]、Belfer Center的TAPP项目^[61]以及Brookings Institution^[62]均对此有深入分析。

6. 高级防御策略与未来展望

应对人工智能复杂的安全挑战，需要超越传统的安全思维，发展和应用高级防御策略与新兴技术，并持续探索未来方向。这需要技术创新、标准化、人才培养和跨领域合作的共同努力。

6.1. AI红队测试与高级防御框架

• AI红队测试：定义、目标（验证防御、评估检测/响应能力）、方法论（模拟对抗攻击、模型窃取等）。 AI红队测试（AI Red Teaming）是一种积极、主动的安全评估方式[^1, ^5]。它模拟真实攻击者（即红队）针对AI系统进行攻击，以系统性地发现AI系统在数据、模型、基础设施和应用层面的安全漏洞，并验证现有防御措施（即蓝队防线）的有效性，评估组织检测和响应AI安全事件的能力^[1:137]。AI红队测试是发现未知漏洞、评估系统真实安全态势的重要手段。

  AI红队测试的方法论包括但不限于：

  • 模拟数据投毒： 尝试向AI系统的数据管道或训练数据源注入恶意样本。
  • 生成对抗样本： 为目标模型生成对抗样本，测试模型的鲁棒性。
  • 尝试模型窃取： 通过查询API或探测基础设施，尝试复制或窃取模型。
  • 探测API漏洞： 对AI模型API进行模糊测试、注入测试等，发现认证、授权和输入验证漏洞。
  • 测试Agent逻辑缺陷和Prompt注入： 针对AI Agent，测试其对恶意Prompt、不安全插件或外部恶意信息的响应，发现其业务逻辑漏洞和权限滥用风险。
  • 评估模型的偏见和有害输出： 系统性地测试模型是否会产生歧视性、有害或不真实的内容。

  这是一种持续性的过程，有助于组织在攻击发生前发现并加固薄弱环节，提升整体安全成熟度[^176]。一些机构和平台提供了AI红队测试指南和工具，例如OWASP GenAI Security Project提供了LLM渗透测试指南[^5, ^128]。

• 高级防御框架： 多种高级防御框架为构建AI安全体系提供了指导和工具[^1, ^5]。它们帮助组织系统地理解AI风险，并构建多层次的防御体系。

  • Google Secure AI Framework (SAIF)： 提供了一套安全实践指南和风险自评估工具，帮助组织在设计和部署AI系统时考虑安全性，强调“安全设计”和内置安全措施[^1, ^7]。SAIF提供了一个框架地图，将AI生命周期的各个阶段与安全控制措施关联起来^[6:7]。
  • MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems)： 提供了一个AI攻击技术分类和知识库[^1, ^5, ^8, ^134, ^135]。它以矩阵形式列出了AI系统可能面临的攻击技术，包括14个攻击阶段和66个策略[^1, ^5]。这有助于安全团队理解AI威胁全景，指导威胁建模、红队测试和防御体系建设，帮助组织更好地识别自身AI系统的攻击面。
  • OWASP GenAI Security Project： 这是从OWASP Top 10 for LLM Applications（2023年发布，2025年更新并升级为旗舰项目）升级而来的更全面的AI安全框架[^5, ^128, ^153, ^46]。它涵盖了AI威胁情报、AI安全治理、安全AI应用开发、Agent应用安全、AI数据安全、红队评估等多个方面[^5, ^41]。它为安全专业人士提供了针对生成式AI和LLM的具体安全实践指导，包括详细的漏洞描述和缓解建议[^11, ^28, ^46]。
  • NIST AI Risk Management Framework (AI RMF)： 提供了一个灵活的、自愿性的AI风险管理方法，包括风险管理行动（情境映射、风险量化、风险管理、风险治理）和AI系统各组件及生命周期阶段的视图[^1, ^5, ^113]。它是一个高层框架，可以与其他具体技术框架结合使用，指导组织建立全面的AI风险管理流程。
  • ISO/IEC 42001： 关于人工智能管理体系的标准，为组织建立、实施、维护和持续改进AI管理体系提供指导，有助于将AI安全和伦理考量融入组织整体管理流程[^1, ^5, ^11]。

• “以模制模”：用AI驱动安全检测与对抗的思路。 利用AI技术本身来提升安全防护能力，例如：

  • 使用机器学习模型检测网络异常行为、识别恶意代码、预测潜在攻击。
  • 利用自然语言处理技术分析安全日志、告警和威胁情报。
  • 使用生成式AI自动化生成安全报告、编写安全策略、甚至辅助编写安全代码[^94]。
  • 利用AI模型对自身或其他AI系统的行为进行监控，检测异常（如模型漂移、输出异常）。
  • 利用AI生成对抗样本来测试模型的鲁棒性。 这种“以模制模”或“AI for Security”的思路，是应对AI安全挑战的重要方向，能够帮助安全团队更快地响应不断变化的威胁态势^[3:40]。

• AI驱动的红队工具（Microsoft PyRIT）。 一些工具正在利用AI自动化部分红队测试任务。例如，**Microsoft的PyRIT（Python Risk Identification Tool for GenAI models）**是一个开源工具，旨在帮助安全研究人员和AI开发者自动化对生成式AI系统的风险识别和红队测试^[52:7]。它可以自动化生成大量Prompt，用于探测LLM的漏洞（如Prompt注入、数据泄露），从而提升红队测试的效率和覆盖范围。

6.2. 新兴AI安全工具与技术

随着AI技术的发展，新的安全工具和技术也应运而生，旨在解决AI特有的安全问题[^1, ^2, ^5]。

• Confidential AI：基于可信执行环境（TEE）保护AI/ML工作负载数据和模型。机密计算（Confidential Computing）是一种利用硬件级别的可信执行环境（TEE，如Intel SGX, AMD SEV, ARM TrustZone）来加密保护正在使用中的数据[^1, ^70, ^26]。Confidential AI将机密计算应用于AI/ML工作负载，确保敏感训练数据和模型参数在训练和推理过程中处于加密状态，即使在云环境中也能防止云服务商或未授权访问者（包括管理员）窃取数据或模型[^1, ^70]。这为在不可信环境中处理敏感AI工作负载提供了强大的隐私和安全保障。

• AI防火墙/护栏（Guardrails）：作为数据代理层控制AI应用数据流，进行输入过滤、输出审核。 AI防火墙或护栏（Guardrails），有时也称为安全护栏，部署在用户输入和AI模型之间，或AI模型和用户输出之间，作为数据代理层^[3:41]。它们通过预设的规则或另一个AI模型对输入进行过滤（如检测恶意Prompt、敏感信息、不安全指令），对输出进行审核（如检测有害内容、虚假信息、泄露敏感信息），从而控制AI应用的输入输出，降低滥用风险^[3:42]。例如，NVIDIA NeMo Guardrails是一个开源工具，用于为LLM应用添加可编程的安全护栏，定义对话主题、阻止特定主题、检测和响应不安全或不当的用户输入和模型输出^[52:8]。

• 智能水印/数字签名：验证AI生成内容的来源和完整性，对抗深伪。 为了对抗深伪和虚假信息，可以在AI生成的内容（图像、视频、文本、音频）中嵌入不可感知或难以移除的水印（智能水印）或使用数字签名，以证明内容的来源和完整性^[1:138]。这有助于接收者验证内容的真实性，区分真实内容与AI合成的虚假内容，并可能用于追溯内容的生成源。C2PA（内容来源与真实性联盟）等标准正在推动AIGC内容来源和标识的标准化[^2, ^6]。

• 知识链框架：保证Agent知识库的可信度。 针对RAG系统知识库投毒的风险，可以构建知识链框架或类似的技术，记录知识库中信息的来源、修改历史和验证状态，利用加密技术（如哈希链、区块链）确保知识的完整性和可追溯性，从而确保Agent获取的信息是可信的^[1:139]。

• 深度伪造检测工具。 开发和部署能够自动化检测深度伪造内容（如换脸视频、克隆语音）的工具，利用AI技术识别合成内容的痕迹，以帮助区分真实内容与AI合成的虚假内容^[1:140]。

• 工业级安全基准测试（如Google AI Safety Benchmark）：涵盖大量安全测试场景。 建立和推广工业级的AI安全基准测试，如Google的AI Safety Benchmark，包含大量预定义的对抗性测试场景，用于量化评估AI模型的安全能力^[1:141]。这些基准测试涵盖多种攻击类型（如Prompt注入、越狱、数据泄露、偏见、有害内容生成等），有助于提升AI产品的整体安全水平，并为模型间的安全性比较提供客观标准。SafeBench是另一个包含多种AI安全评估基准的套件^[54:1]。

• AI安全评估平台（AIcert）：理论验证、安全开发、多维分析。 专业的AI安全评估平台（如AIcert）提供从理论验证（基于形式化方法验证模型属性）到安全开发流程（集成安全检查）、再到模型多维分析（如鲁棒性、可解释性、偏见分析）的综合能力，帮助企业系统性地评估AI系统的安全性^[55:5]。

• AI驱动的软件供应链安全分析平台（VackSCA）：基于AI的二进制代码相似性比较。 利用AI技术分析软件供应链中的组件安全，例如VackSCA（深链）平台利用AI进行二进制代码相似性比较，无需源代码即可检测软件漏洞和潜在的恶意修改，有助于发现开源组件或第三方库中的隐藏风险^[55:6]。

6.3. 未来趋势与研究方向

人工智能安全是一个快速演进的领域，未来的研究和实践将聚焦以下几个关键趋势：

• MLSecOps体系的成熟与普及： 实现开发运维与AI安全治理的深度融合仍然面临跨部门协作、工具链整合（将AI特有安全工具无缝集成到现有DevOps平台）和标准化等挑战^[1:142]。未来的趋势是将MLSecOps建设成为AI开发组织的标配流程，并形成更加成熟的框架、最佳实践和自动化工具链，实现AI安全的“管道化”和“平台化”^[3:43]。
• 运行时AI安全： AI模型的非确定性^[1:143]和动态性使得静态安全措施不足。推理阶段的实时保护、监控和威胁响应将变得更加重要^[1:144]。需要开发能够在模型运行时检测和阻止攻击（如提示词注入、对抗攻击）的技术，例如AI防火墙、运行时模型行为监测和自适应调整机制。
• 零信任架构在AI系统集成中的应用： 随着AI系统与企业内外部系统深度集成，攻击面扩大，需要采用零信任架构，不信任任何用户或系统，所有交互都需经过严格认证、授权和持续验证，确保只有经过验证的用户和工作流才能以最小权限与AI系统交互^[3:44]。
• Agent安全与多模态模型安全： 随着具备自主性、工具调用能力、多Agent协作能力的Agent和处理文本、图像、音频等多种数据的多模态AI模型的普及，针对这些新兴AI范式的特定安全威胁（如Agent协作风险、多模态对抗攻击、跨模态Prompt注入）和防御技术将成为研究重点^[1:145]。
• AI安全标准的制定与落地： 全球范围内AI安全标准的制定和推广将加速，涵盖风险评估、数据安全、模型安全、可解释性、伦棒性等多个方面[^1, ^5]。如何将这些高层标准有效地落地到企业的AI开发和运营实践中，转化为具体的工程规范和测试指标是关键。
• 跨领域人才培养（ML工程师 + 安全专家）： AI安全需要融合AI、网络安全、数据科学、法律伦理等多方面的知识。目前同时具备这些技能的复合型人才非常稀缺^[3:45]。弥合机器学习和网络安全领域的知识鸿沟，培养跨领域人才至关重要。
• 应对LLM非确定性带来的安全挑战： 大型语言模型的非确定性输出增加了安全防护的难度，使得基于确定性规则的安全策略难以完全适用^[1:146]。如何建立可靠的护栏和验证机制，确保模型在自由生成的同时，输出的内容是安全、可靠且符合预期的，是未来的重要研究方向。
• 常态化、多元协同的AI风险监测与应急机制： 建立国家、行业、企业层面的常态化AI风险监测体系，及时发现和预警新的攻击手段和漏洞。构建多方参与（包括政府、企业、研究机构、社会组织）的多元协同应急响应机制，共同应对大规模AI安全事件或潜在的失控风险^[1:147]。

7. 结论

人工智能作为一项革命性的技术，其安全风险治理已成为保障其健康可持续发展的核心议题。本文从预训练阶段的数据投毒、模型窃取、算法对抗，到部署阶段的基础设施“裸奔”与云端API漏洞，再到AI应用特别是Agent面临的新兴威胁，以及更宏观的监管合规、伦理考量与地缘政治影响，全面而深入地剖析了AI全生命周期所面临的复杂而严峻的安全挑战。这些风险不仅影响AI系统的可靠性与可用性，更可能侵犯隐私、加剧偏见、引发伦理困境，甚至对国家安全构成威胁。传统孤立的安全措施已不足以应对AI特有的风险特性和复杂性。

将DevSecOps的理念与自动化实践深度融入AI生命周期治理，形成MLSecOps框架，是当前应对这些挑战的有效路径。它强调安全左移，在数据准备和模型设计阶段就植入安全基因；强调自动化，将安全检测、测试、防护集成到CI/CD流水线；强调持续监控，对AI系统行为进行实时监测与响应；强调协作文化，打破团队壁垒。借助自动化工具链（包括AI特有的红队工具、模型安全扫描器、AI防火墙等）和高级防御策略（如Confidential AI、智能水印），MLSecOps能够有效地提升AI系统的安全韧性。

然而，AI安全治理并非仅是技术工程，它深刻地置身于全球监管、伦理道德和地缘政治的宏大背景之下。理解欧盟、美国、中国等主要经济体不同的AI监管路径和AIGC标识要求，正视AI带来的算法偏见、隐私侵犯、虚假信息等伦理和社会挑战，以及应对AI作为战略技术引发的地缘政治博弈，都是构建鲁棒AI安全体系不可或缺的组成部分。

未来的AI安全之路，将是一场持续的技术对抗、治理模式创新与社会价值适应的复杂进程。构建一个安全可信的人工智能生态体系，需要技术创新（发展更先进的防御技术、AI驱动的安全工具）、管理优化（深化MLSecOps实践、建立标准化的治理流程）、法规完善与伦理约束、以及国际社会在构建全球治理框架上的共同努力。同时，培养跨领域人才、提升全社会AI安全素养、构建多方参与的治理生态也至关重要。这不仅是技术界的任务，更是全社会需要共同面对和解决的时代命题。通过持续的研究、审慎的治理和负责任的应用，我们才能充分释放AI的巨大潜力，同时有效管控其带来的风险，最终实现人机和谐共存的智能未来。

8. 参考文献

[其他参考文献，根据需要从提供的search结果和PDF中整理补充]

[其他参考文献，根据需要从提供的search结果和PDF中整理补充]

贡献者

pansin

文件历史

最后编辑于 11 天前查看完整历史

eb57f-Add bulk markdown knowledgebase content

---

1. Artificial Intelligence Lifecycle Security Risk And Devsecops Governance Framework Analysis.md (分析结论) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

2. search 预训练模型数据投毒风险.md (搜索结果) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

3. search 训练算法对抗攻击与模型窃取.md (搜索结果) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

4. Xiang, Z., et al. (2025). RAGForensics: Tracing Back Poisoned Texts in Poisoning Attacks to RAG. arXiv:2504.21668v1. ↩︎ ↩︎ ↩︎ ↩︎

5. Goldblum, M., et al. (2025). Can We Unlearn Data Poisoning? On the Ineffectiveness of Machine Unlearning for Data Poisoning Defenses. arXiv:2406.17216v2. ↩︎

6. Meng, W., et al. (2025). R.R.: Unveiling LLM Training Privacy through Recollection and Ranking. arXiv:2502.12658. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

7. Zhang, Y., et al. (2025). Mitigating Sensitive Information Leakage in LLMs4Code through Machine Unlearning. ResearchGate. ↩︎ ↩︎ ↩︎ ↩︎

8. Papadaki, M., et al. (2025). PMixED: Differentially Private Model Explanations from the Input Space. arXiv:2403.15638v1. ↩︎ ↩︎ ↩︎ ↩︎

9. Bu, Z., et al. (2025). Privacy, Utility and Efficiency in Fine-tuning Large Language Models. arXiv:2502.13313v1. ↩︎ ↩︎ ↩︎

10. Liu, Y., et al. (2024). Privacy-Preserving Mechanisms for Large Language Models: A Survey. arXiv:2412.06113v1. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

11. Cohen, G., & Nissim, N. (2025). Zero-Trust Artificial Intelligence Model Security Based on Moving Target Defense and Content Disarm and Reconstruction. arXiv:2503.01758. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

12. Ding, Z., et al. (2025). A Rusty Link in the AI Supply Chain: Detecting Evil Configurations in Model Repositories. arXiv:2505.01067. ↩︎ ↩︎ ↩︎ ↩︎

13. García Veytia, A. (2024, March 14). Securing the AI/ML model supply chain: Where's the data? Stacklok Blog. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

14. Bennet, K., et al. (2025). Implementing AI Bill of Materials (AI BOM) with SPDX 3.0: A Comprehensive Guide to Creating AI and Dataset Bill of Materials. arXiv:2504.16743. ↩︎

15. Diaz-Pinto, A., et al. (2025). Detecting Dataset Bias in Medical AI: A Generalized and Modality-Agnostic Auditing Framework. arXiv:2503.09969. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

16. Bartal, A., et al. (2024). A Review of Fairness and A Practical Guide to Selecting Context-Appropriate Fairness Metrics in Machine Learning. ResearchGate. ↩︎ ↩︎ ↩︎ ↩︎

17. Alashaikh, A., et al. (2025). Bias-Aware Agent: Enhancing Fairness in AI-Driven Knowledge Retrieval. arXiv:2503.21237. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

18. search 欧盟美国中国人工智能监管法规2023..2025.md (搜索结果) ↩︎

19. search 云端AI模型API安全漏洞.md (搜索结果) ↩︎

20. search MLSecOps最新进展与挑战.md (搜索结果) ↩︎

21. search 人工智能Agent安全与隐私保护.md (搜索结果) ↩︎ ↩︎ ↩︎ ↩︎

22. Pinto, A. D., et al. (2022). Bias and Unfairness in Computer Vision Applications of Machine Learning for Law Enforcement. FAccT '22. ↩︎ ↩︎

23. Li, Y., et al. (2024). BackdoorLLM: A Comprehensive Benchmark for Backdoor Attacks on Large Language Models. arXiv:2408.12798v2. ↩︎ ↩︎ ↩︎

24. Understanding and Preventing AI Model Theft: Strategies for Enterprise | NeuralTrust. (n.d.). ↩︎ ↩︎

25. Mitigating AI cybersecurity risks with Bug Bounty Programs - YesWeHack. (n.d.). ↩︎

26. Security considerations when hosting AI models on GPU servers - Liquid Web. (n.d.). ↩︎ ↩︎ ↩︎ ↩︎

27. Liu, Y., et al. (2025). Federated Fine-tuning of Large Language Models: A Survey of Current Methods and Future Directions. arXiv:2501.04436v1. ↩︎ ↩︎ ↩︎

28. Zhang, J., et al. (2024). Federated Learning for Large Language Models: A Survey on Architecture, Challenges, and Opportunities. arXiv:2406.09831v2. ↩︎ ↩︎

29. Li, B., et al. (2025). DropPEFT: A Dropout-based Parameter-Efficient Fine-Tuning Method for Federated Large Language Models. arXiv:2503.10217v1. ↩︎

30. Zhang, Z., et al. (2025). Layer-Skipping Federated Learning for Large Language Models. arXiv:2504.10536v1. ↩︎

31. Alsadhan, A., et al. (2025). FAS: Fast and Secure Federated Learning with Selective Homomorphic Encryption, Differential Privacy and Bit-wise Scrambling. arXiv:2501.12911v1. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

32. Zhao, Z., et al. (2024). Confidential Prompting with Cloud Virtual Machines. arXiv:2409.19134v3. ↩︎ ↩︎

33. Li, Z., et al. (2024). Privacy-Preserving Machine Learning: A Comprehensive Survey on Techniques and Applications. arXiv:2403.03592. ↩︎ ↩︎

34. Liu, X., et al. (2025). Privacy-Preserving Large Language Models: A Survey. arXiv:2505.17145v1. ↩︎

35. Artificial Intelligence and the Insider Threat - CDSE. (n.d.). ↩︎

36. Building On Prem Agentic AI Infrastructure - A Complete Guide - XenonStack. (n.d.). ↩︎

37. OWASP. (n.d.). OWASP API Security Project. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

38. LLM Prompt Injection Prevention - OWASP Cheat Sheet Series. (n.d.). ↩︎ ↩︎

39. AWS. (n.d.). Data Protection in Amazon SageMaker AI. Amazon SageMaker Developer Guide. ↩︎ ↩︎ ↩︎ ↩︎

40. Google Workspace. (2021, October). Google Workspace security whitepaper. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

41. A Risk-Based Approach to AI Security in Microsoft Azure - ArcherPoint. (n.d.). ↩︎ ↩︎ ↩︎

42. Microsoft. (n.d.). Security for AI. Microsoft Security. ↩︎ ↩︎ ↩︎

43. Key Management - Amazon SageMaker AI - AWS Documentation. (n.d.). ↩︎

44. Internetwork Traffic Privacy - Amazon SageMaker AI. (n.d.). ↩︎

45. Google Workspace. (n.d.). Cloud Security and Data Protection Services. ↩︎

46. Prompt Injection attack against LLM-integrated Applications - arXiv. (n.d.). ↩︎

47. arXiv. (n.d.). arXiv:2505.08728. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

48. Beyond RPA: Implementing Secure AI Agent Access | Oasis Security. (n.d.). ↩︎ ↩︎ ↩︎

49. Mitigating the Privacy Issues in Retrieval-Augmented Generation (RAG) via Pure Synthetic Data - arXiv. (n.d.). ↩︎ ↩︎ ↩︎ ↩︎

50. Optimizing RAG for Sensitive Data & Privacy Compliance - Chitika. (n.d.). ↩︎

51. 30 Best Tools for Red Teaming: Mitigating Bias, AI Vulnerabilities & More - Mindgard. (n.d.). ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

52. MLSecOps: Top 20+ Open Source and Commercial Tools - Research AIMultiple. (n.d.). ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

53. JFrog Becomes an AI System of Record, Launches JFrog ML – Industry's First End-to-End DevOps, DevSecOps & MLOps Platform for Trusted AI Delivery. (n.d.). ↩︎ ↩︎

54. ML Safety. (2024). Announcing the SafeBench Winners. ↩︎ ↩︎

55. search DevSecOps在人工智能安全中的应用.md (搜索结果) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

56. 全国信息安全标准化技术委员会. (2023). 网络安全技术 人工智能计算平台安全框架 (征求意见稿). ↩︎

57. 全国信息安全标准化技术委员会. (2024). 网络安全技术 生成式人工智能预训练和优化训练数据安全规范. ↩︎ ↩︎

58. search AI伦理风险与社会影响最新研究.md (搜索结果) ↩︎

59. search 人工智能私有化部署安全挑战.md (搜索结果) ↩︎

60. Technology & National Security | CNAS. (n.d.). ↩︎

61. Technology and Public Purpose | The Belfer Center for Science and International Affairs. (n.d.). ↩︎

62. Artificial Intelligence | Brookings. (n.d.). ↩︎